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ABSTRACT 


This thesis presents an effeetive methodology and tool set, that explicitly 
considers technological uncertainty, to enable design, development, and assessment of 
alternative system concept architectures for an autonomous unmanned surface vessel 
(USV) in a system of systems (SoS) context. 

Complex system designs often fail due to poor communication of customer needs 
and inadequate understanding of the overall problem. This frequently results in the 
design team missing the mark in transforming requirements into a successful conceptual 
design. Effective system design requires a defined, flexible, and structured context 
within which new technological ideas can be judged. Alternative physical architectures 
are then modeled, simulated, and compared to find the “best” solution for further 
examination. 

This thesis uses model-based systems engineering (MBSE) principles to develop a 
multi-criteria decision making (MCDM) model that allows designers to perform a 
solution neutral investigation of possible alternative physical architecture concepts. This 
ensures a consistent quantitative evaluation of warfighting capability, suitability, 
effectiveness, technology maturation, and risk before and during a program execution. 
This effort is in support of an extended program to design a system of unmanned systems 
intended to provide the DoD with a coordinated, multi-domain, multi-mission, 
autonomous security and warfighting asset. 
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EXECUTIVE SUMMARY 


Like all engineering projects, this thesis began with a question: How do 
Department of Defense (DoD) engineers efficiently and effectively design an 
autonomous surface vessel in support of an overarching Office of Naval Research (ONR) 
Unmanned Vehicle (UV) system of systems (SoS)? 

Traditional DoD engineering practices include a threat-based or technology- 
driven design process, focusing on the system components the designers feel will 
effectively counter an adversary’s current and future capabilities. This bottom-up 
approach to system design typically misses the mark in meeting stakeholder capability 
needs and fails to effectively perform the intended mission. The process typically results 
in the designer following predetermined design concepts leading to an unfavorable 
solution. In addition, the approach almost always results in allocating large amounts of 
money and assets in areas that are well outside the feasible design region of the project, 
wasting valuable resources better spent elsewhere. 

This thesis offers an alternative approach to this engineering problem based on a 
capabilities-driven, model-based, SoS engineering process. This holistic approach to 
system design keeps the design concepts and the designer in the feasible region with 
respect to physical, systematic, and capability constraints. It presents an effective 
methodology and tool set to enable design, development, and assessment of alternative 
system concept architectures for an autonomous unmanned surface vessel (USV) in a SoS 
context. 

Using model-based systems engineering (MBSE) principles and a derived multi¬ 
criteria decision making (MCDM) model allow designers to perform a solution neutral 
investigation of possible alternative physical architecture concepts. This ensures a 
consistent quantitative evaluation of warfighting capability, suitability, effectiveness, 
technology maturation, and risk before and during a program execution. This effort is in 
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support of an extended program to design a system of unmanned systems intended to 
provide the DoD with a eoordinated, multi-domain, multi-mission, autonomous seeurity 
and warfighting asset. 
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I. 


INTRODUCTION 


A. OVERVIEW 

This thesis presents an effective methodology and tool set to enable design, 
development, and assessment of alternative system concept architectures for an 
autonomous unmanned surface vessel (USV) in a SoS context. The methodology 
provides a consistent quantitative evaluation of warfighting capability suitability, 
effectiveness, technology maturation, and risk before and during a program execution. 
This effort is in support of an extended program to design a system of unmanned systems 
intended to provide the DoD with a coordinated, multi-domain, multi-mission 
autonomous security and warfighting asset. 

The methodology is capabilities-driven, based on thorough generation and review 
of mission-based ability to deliver a set of desired effects. The MBSE method allows for 
solution neutral investigation of possible alternative physical architecture concepts to 
meet overall SoS needs based on a traceable path to the capabilities desired as 
documented by the stakeholders. The method developed provides the best way to 
compare alternative architectures and assess technological maturity of critical subsystems 
in meeting stakeholder capability needs. 

The architecture structure is created, defined, edited, and configuration controlled 
and managed using Vitech CORE. Einkages to engineering feasibility analysis are 
accomplished using Microsoft Excel, though other domain specific science, engineering, 
and analysis software tools could also be used. Design space creation, exploration, and 
trade-off is accomplished using Microsoft Excel and Statistical Analysis Software (SAS) 
Institute JMP. Technology assessments and associated uncertainty analyses are 
accomplished using SAS Institute JMP. 

Unmanned vehicle (UxV) systems are particularly susceptible to missing the mark 
in meeting stakeholder needs, especially due to advanced concepts, inclusion of uncertain 
technology, the need to fuse diverse elements, multifaceted integration issues, and the 
manifestation of emergent properties. SoS are described as (Boardman and Sauser 2008) 
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... a large-scale, complex system, involving a combination of components 
which are systems themselves, achieving a unique end-state by providing 
synergistic capability from its component systems, and exhibiting a 
majority of the following characteristics: operational and managerial 
independence, geographic distribution, emergent behavior, evolutionary 
development, self-organization, and adaptation. 

Designing a SoS requires an architecture development method that implements 
executable architectures that can be used to model and simulate behaviors during the 
design process. 

System architecture development is based on systems engineering principles and 
involves expanding the areas of identifying a capability gap or need, defining and 
refining architectural and engineering system requirements, analyzing system functions, 
allocating system functions to physical components, and the application of executable 
models. Building the UV Sentry system of systems architecture requires a thorough 
MBSE method to ensure success in meeting stakeholder capability needs and 
transforming them into an effective SoS design. 

The first three chapters of this thesis build a solid knowledge base of the concepts 
and techniques behind this innovative method. Chapter I provides a necessary overview 
of the engineering and architecture development terms, processes, and concepts involved 
with the design approach. Chapter II provides a description of the UV Sentry system as a 
whole and the unmanned surface vehicles aspects of the system of systems. Chapter III 
describes the elements and techniques used in building the system architecture and 
model-based design tools. The final two chapters describe how to build and use the 
MCDM model. Chapter IV presents the architecture development and analysis method 
for the UV Sentry unmanned surface vessel using the tools and techniques described in 
the first three chapters. Chapter V provides a summary, conclusions, and 
recommendations for follow-on work. 

This thesis provides UV sentry designers with the appropriate tools and processes 
to effectively focus their research and acquisition efforts. This focus will prevent the 
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unnecessary disbursement of resources into non-critical or unfeasible areas. This will 
permit system designers to focus efforts in areas where they are needed and will have a 
positive effect on the overall design. 


B. BACKGROUND 

Unmanned systems have increasingly become an integral element of a wide range 
of modern military operations over the past decade. Unmanned systems performed vital 
roles on the ground, in the water, and in the skies during military operations in Iraq and 
Afghanistan. The DoD anticipates these systems will play an even larger role in future 
military operations. The Secretary of Defense’s Unmanned Systems Integrated Roadmap 
FY 2009-2034 highlights this with: 

In today’s military, unmanned systems are highly desired by combatant 
commanders (COCOMs) for their versatility and persistence. By 
performing tasks such as surveillance; signals intelligence (SIGINT); 
precision target designation; mine detection; and chemical, biological, 
radiological, nuclear (CBRN) reconnaissance, unmanned systems have 
made key contributions to the Global War on Terror (GWOT). As of 
October 2008, coalition unmanned aircraft systems (UAS) (exclusive of 
hand-launched systems) have flown almost 500,000 flight hours in support 
of Operations Enduring Freedom and Iraqi Freedom, unmanned ground 
vehicles (UGVs) have conducted over 30,000 missions, detecting and/or 
neutralizing over 15,000 improvised explosive devices (lEDs), and 
unmanned maritime systems (UMSs) have provided security to ports.” 

The report continues: “In response to the Warfighter demand, the 
Department has continued to invest aggressively in developing unmanned 
systems and technologies. That investment has seen unmanned systems 
transformed from being primarily remote operated, single-mission 
platforms into increasingly autonomous, multi-mission systems (OSD 
2009). 

The vulnerability of personnel and high value assets coupled with the high cost of 
manned platforms fuels the drive for the UV Sentry SoS. The asymmetric nature of the 
threats and the vast coverage areas intensify the need to have a coordinated network of 
unmanned vessels to accomplish the dirty, dull, and dangerous tasks that are now 
performed with manned assets. The UV Sentry vision involves a versatile fusion of 
unmanned surface, subsurface, and airborne vehicles, hereafter generically referred to as 
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(UxV), accomplishing a broad set of capabilities providing persistent effeetive defense of 
naval and maritime assets using manned and unmanned systems. The system will provide 
information, surveihanee, and reeonnaissanee (ISR) to improve situational awareness 
around a high-value asset (or group of assets). This SoS will take aetion at suffleient 
distanees to neutralize or deter deteeted threats, autonomously operating and sharing 
information between system elements. 

The DoD vision of future operations ealls for vastly improved autonomous 
vehieles and greater synergy between air, ground, and maritime assets. The multitude of 
missions, domains, and environments eoupled with the asymmetrieal nature of the threats 
adds an unpreeedented level of eomplexity faeilitating the need for a SoS engineering 
approaeh to the problem. The eurrent seope of the majority of unmanned vehiele 
programs is bound within a limited mission in a single domain. The UV Sentry initiative 
seeks to expand this seope to eover a multitude of seeurity related missions in three 
domains (air, surfaee, and sub-surfaee). Although the teehnology maturation for a fully 
eoordinated, multi-domain, multi-mission, fleet of autonomous vehieles is a work in 
progress, a elear and eoordinated plan is required to develop a future unmanned system of 
systems. The UV Sentry program is eommitted to providing a eoordinated effort in 
transforming disjointed, stand-alone, unmanned vehiele initiatives into a eohaborative 
design and aequisition approaeh. This approaeh is intended to set a solid foundation for 
future UV researeh, development, and aequisition. Without this integrated approaeh to 
foree applieation and mission aoeomplishment, the projeet will most hkely lead to an 
ineffeetive and disordered design. 

C. OBJECTIVES 

The overall objeetive of this thesis is to set the foundation for the development of 
a system of systems arehiteeture development and engineering design proeess that for the 
development of the future U.S. DoD UV Sentry SoS. 
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This Thesis: 

• Provides a synopsis of the fundamental design eoneepts used. 

• Explains the seope and methodology of the projeet. 

• Provides an overview of unmanned systems, the UV Sentry initiative, and 
autonomous surfaee eraft missions, elassifieations, and design eoneerns. 

• Provides an overview of the design tools and teehniques used in this 
projeet. 

• Deseribes how to build the model. 

• Deseribes a real-world example of the proeess using aetual ship synthesis 
information. 

• Briefly covers how statistical methods can be used to study the impact of 
stochastic inputs and uncertainty in conceptual design. 

• Provides a summary, conclusions, and recommendations based on this 
study’s findings. 

D. CONTEXT 

The UV Sentry program is implementing the development process shown in 
Figure 1. This section provides a synopsis of the fundamental design concepts used in 
this process, and applied to a specific methodology is used to accomplish a MBSE trade 
study analysis for the UV Sentry program. 
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Figure 1. UV Sentry Arehitecture Synthesis. (From: (Whitcomb et al. 2008)) 


1. Capabilities-Based Planning (CBP) 

CBP is a systematic force development approach that aims to develop the most 
appropriate options to meet priorities such as strategic objectives, cost and risk 
minimization, and constraint compliance (TTCP 2007). This method involves a 
functional analysis of operationally required capabilities based on the tasks required to 
perform the respective mission(s). Once the capabilities are defined, the most cost 
effective and efficient options that satisfy the requirements are sought (TTCP 2007). 
Figure 1 shows the capabilities-based development method embedded in the SE process. 
The Capability Pull loop ensures capability needs are iteratively reviewed, analyzed, and 
revised throughout the SE process. 

This development process marks a transformation in DoD’s approach to system 
requirements definition and defense planning from a from a “threat-based” to a 
“capabilities-based” model. This process focuses on identifying the capabilities required 
to solve a problem and delivering those capabilities to the system. CBP attempts to 
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eradicate traditional stovepipes, making the planning process more lucid, rational, and 
responsive to uncertainty, economic constraints, and risk. The CBP process focuses on 
overarching goals and end-states supporting analysis, facilitating risk management, and 
encouraging innovation. CBP forces system designers to ask what do we need to do 
rather than what equipment are we replacing (TTCP 2007). CBP uses scenarios to 
provide the context within which the system will operate. This context is then used to 
determine what capabilities are required for the system to meet its stated needs and how 
to measure its level of capacity. Capabilities, often referred to as operational scenarios, 
consist of a sequence of operational activities needed to respond to or to provide an 
external stimulus (Whitcomb et al. 2008). Anticipated operational scenarios are 
developed in support of a higher-order concept of operations (CONOPS) that describes 
the anticipated strategic, operational, and tactical levels of system employment. Valid and 
well-defined CONOPS are essential inputs to a successful capabilities-based 
planning/design process. The CONOPS, and associated operational scenarios, drive the 
conceptual design process and provides a means for developing goals against which 
capabilities are assessed (TTCP 2007). 

The capabilities-based approach is realized in the DoD through the Joint 
Capabilities Integration Development System (JCIDS). JCIDS is the DoD’s principal 
decision-making process for transforming the military in support of future strategic goals. 
JCIDS uses a collaborative process, utilizing joint concepts and integrated architectures, 
to identify capability gaps and approaches to bridge them (CJCS 2009). A capability need 
is a required function that a system must possess within specified conditions and to 
essential performance levels. A capability gap is the inability to achieve a desired effect 
under specified conditions and standards through combinations of resources and 
techniques to perform a set of tasks (CJCS 2009). A Capabilities-Based Assessment 
(CBA) is conducted, in accordance with JCIDS, to identify capability needs, gaps, 
excesses, and approaches to provide needed capabilities within a specified functional or 
operational area (CJCS 2009). Once the CBA is complete and the required capabilities 
are identified, the JCIDS process works to transform capabilities into solutions. 
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Implementation of this eapability-based development proeess is the front-end to 
the system aequisition and development proeess, whieh must keep the proeess foeused on 
the problem spaee versus the solution spaee (Whiteomb et al. 2008). The outeome is the 
system arehiteeture, whieh defines system funetions, elements, and relationships. The 
arehiteeture is the embodiment of the system and should be understood and agreed upon 
by all stakeholders and validated to meet all established eapability needs. 

2. Systems Engineering Process (SEP) 

The DoD defines systems engineering as: 

Systems engineering is an interdiseiplinary approaeh eneompassing the 
entire teehnieal effort to evolve and verify an integrated and total life eyele 
balaneed set of system, people, and proeess solutions that satisfy eustomer 
needs. Systems engineering is the integrating meehanism aeross the 
teehnieal efforts related to the development, manufaeturing, verifieation, 
deployment, operations, support, disposal of, and user training for systems 
and their life eyele proeesses. Systems engineering develops teehnieal 
information to support the program management deeision-making proeess 
(OSD 2002). 

Systems engineering is typieally deseribed as having two domains: the teehnieal 
knowledge domain in whieh the systems engineer operates; and the systems engineering 
management domain where the projeet management oeeurs (OSD 2002). 

The Systems Engineering Proeess (SEP), displayed in Eigure 2, is a 
eomprehensive, iterative and reeursive problem solving proeess, for transforming needs 
and requirements into a set of system produet and proeess deseriptions. The proeess is 
applied sequentially, one level at a time, adding additional detail and definition with eaeh 
level of development (OSD 2002). This proeess typieally begins by identifying the 
problem and assoeiated stakeholders. The problem is then properly defined and refined to 
ensure it properly deseribes the eustomer’s need(s). Proeess inputs inelude eustomer 
needs/requirements, teehnology base, and other requirements the system must meet. 

The first step of the proeess is the Requirements Analysis phase. Here system 

missions and environments are analyzed, funetional requirements identified, and design 

eonstraints defined. This step develops a eomprehensive and logieal set of performanee 
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requirements that detail what, where, and how well the system must perform. This step is 
partieularly important as an ill-defined set of requirements will typieally not be met. 

The next part of the SE proeess is the funetional analysis phase. Here funetions 
are deeomposed, requirements are linked to various level funetions, interfaees are 
defined, and the funetional arehiteeture is defined and refined. The funetional arehiteeture 
is the deseription of the produet in terms of what it does. This arehiteeture is illustrated 
with a funetional hierarehy diagram that displays the strueture of higher-level funetions 
and their respeetive derivation to lower-level funetions. This hierarehy provides deeision 
makers with a elear vision of aetual system funetions and how the funetions are 
assoeiated with one another. 




system elements are defined; preferred proeess and produet solutions are selected; and 
internal and external physical interfaces are defined. In general, design synthesis is the 
process of defining the physical architecture of the system in terms of its physical 
elements with each physical element meeting at least one functional requirement. “The 
physical architecture is the basic structure for generating the specifications and baselines” 
(OSD 2002). This phase may also involve the use of development tools such as; trade-off 
studies; risk analysis and management; and interface management. 

Each phase of the process is not complete after its first incidence. The processes 
include recursive loops for an iterative development process. The Requirements loop 
provides feedback from the Functional Analysis section to the Requirements Analysis 
section. This provides the means of mapping requirements to functions and back to make 
certain all functions are linked to a requirement. Any function not linked to a requirement 
is wasted effort; any requirement not linked to a function will never be met. The Design 
loop links the Synthesis and Functional Analysis phases providing a cyclic process for 
mapping functional architecture to physical architecture. This process maintains 
continuity in the systems architecture model, ensuring all functions have physical 
elements to perform them. “The design loop permits reconsideration of how the system 
will perform its mission, and this helps optimize the synthesized design” (OSD 2002). In 
addition to the Design loop, the Synthesis phase involves a Verification feedback element 
to ensure all the requirements are met by the physical architecture. The verification 
process is a formal testing and evaluation method to ensure the proposed solution meets 
all of the requirements. 

The Systems Analysis and Control process provides the control mechanism for 
the iterative SE process. This process step provides general developmental oversight and 
coordination as alternative system approaches are analyzed in each phase of the systems 
engineering process. This oversight is essential in balancing all aspects of the SE process 
including trade-off studies and risk management. In addition, the process assures 
alternative system decisions are made only after their system effectiveness impact is 
evaluated and that product and process design requirements are directly traceable to 
functional and performance requirements (OSD 2002). The primary output of the SE 
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process is the system arehiteeture. The system arehiteeture ineludes the physieal and 
funetional hierarehies and the system speeifieations. The systems engineering proeess 
output provides the neeessary information to illuminate the eoneeptual system design and 
deseribes system eharaeteristies sueh as eost, performanee, and risk. 

3. System of Systems Engineering 

SoS deseribes an integrated arrangement of interoperable systems aeting as a 
single funetional entity to aehieve a mission eapability. A SoS is defined by Boardman 
and Suaser (2008) as: 

...a large-seale, eomplex system, involving a eombination of eomponents 
whieh are systems themselves, aehieving a unique end-state by providing 
synergistie eapability from its eomponent systems, and exhibiting a 
majority of the following eharaeteristies: operational and managerial 
independenee, geographie distribution, emergent behavior, evolutionary 
development, self-organization, and adaptation (Boardman and Sauser 
2008). 

Typieal eharaeteristies of a system of systems inelude a high degree of 
eollaboration and eoordination, flexible addition or removal of eomponent systems, and a 
net-eentrie arehiteeture (ASN RDA 2006). The SoS possesses eapabilities not possessed 
by the simple sum of the eonstituent eapabilities operating separately. Individual SoS 
elements are typieally able to operate independently and may be separately managed. 
Management, organization, integration, and interoperability between the eonstituent 
systems are often major ehallenges for SoS development and implementation. 

A system of systems is often eonfused with a family of systems. In a system of 
systems, subsystems are related or eonneeted to provide a given eapability. The loss of 
any part of the system will degrade the performanee or eapabilities of the whole. In a 
family of systems, subsystems provide similar eapabilities through different approaehes 
to aehieve similar or eomplementary effeets (CJCS 2009). Five prineipal eharaeteristies 
that distinguish systems of systems from monolithie systems are: a SoS is eomposed of 
systems whieh are independent and useful in their own right; managerial independenee of 
the systems; large geographie distribution; evolutionary development; and emergent 
behavior (Sage 1992). 
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SoS engineering is an emerging interdiseiplinary approaeh to transform 
eapabilities into SoS solutions. The architeeture development of an SoS starts with the 
transformation of an operational capability need into a set of requirements, which are 
used to guide the development of functional and physical architectures through design 
(Whitcomb et al. 2008). 

4. System Architecture 

Systems Architecture is “the fundamental organization of a system, embodied in 
its components, their relationships to each other, and to the environment, and the 
principles governing its design and evolution” (IEEE 2000). Systems Architecting is the 
process used to develop and revise the system architecture. Systems architecture 
development, like the SEP, is an iterative process involving participative discovery of 
multiple stakeholders to achieve an end state. In systems architecture development, 
however, the end state is a well-defined, clear, all-inclusive, agreed-upon, systems 
architecture that meets all capability requirements. Systems architects must work to 
reduce ambiguity, minimize complexity, and focus creativity, to transform the capability 
need from the abstract to the concrete through a series of ever-evolving models of 
continually improved fidelity (Southworth 2008). 

Systems architecture development and systems engineering are both essential 
components of the overall systems engineering process, both presenting complementary 
approaches to the development of unprecedented (or as-yet fully conceived) SoS 
(Whitcomb et al. 2008). Architecting focuses on the qualitative aspects of the system and 
typically deals with undefined situations with immeasurable quantities. Engineering 
primarily deals with physical and scientific situations with measurable quantities and 
concepts (Maier and Rechtin 2002). DoD architecture development is directed by the 
JCIDS process and should start early in the systems engineering process and be 
introduced in the earliest part of the acquisition process. System designers must pay 
particular attention not to fall into the trap of trying to describe the total system to the 
individual component level before bounding the requirements and properly developing 
the system architecture. This mistake has the system designer focusing on components 
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rather than capabilities, resulting in an ill-formed architecture. The systems architecture 
development approach focuses on architecture development from capability needs. The 
ultimate goal of systems architecture development is to provide a well-defined system in 
the application domain and system that meets desired capabilities developed in the 
solution domain (Southworth 2008). 

The relationship of the system and the architecture are shown in Figure 3 (IEEE 
2000). A system fulfills a mission and inhabits and influences an environment. A system 
also has stakeholders, who have concerns that must be met through the use of the system. 
A system has an architecture, which is described by a description that provides rationale, 
which is used by the stakeholders to ensure their concerns are addressed. The description 
consists of views that conform to the stakeholder’s viewpoint. A model is used to 
represent the system structure, and allow for reasoning about that structure. Multiple 
architectural “views” are needed to allow stakeholders to communicate with the 
architects and other stakeholders in their own language to ensure their concerns are 
addressed. All views are derived from a single system structure, the architecture model, 
with each view acting as a lens projecting an image in the stakeholder’s own native 
language as defined by their own viewpoint. Architecture, then, exists for the purpose of 
achieving a well-defined system in all domains, such that the eventual system developed 
will meet operator’s desired effectiveness An architecture model is the fundamental basis 
for engineering a system since it is the foundation upon which the entire development 
depends (Whitcomb et al. 2008). 
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Mission 


fulfills 1..* 



Figure 3. IEEE 1471 Conceptual Eramework. (Erom; (IEEE 2000)) 

Complex systems present enormous amounts of elements and interconnections in 
the architecture model. This sheer amount of data, coupled with the need to manipulate, 
change, and display architecture information, facilitates the need for a better means to 
communicate and influence architectural relationships. Architecture frameworks are tools 
for coping with system complexity by structuring data into different views with common 
communication language providing consistency and traceability to system characteristics 
descriptions. The architecture is defined through a series of views, each depicting the 
architecture in a perspective that addresses a respective stakeholder’s needs (Whitcomb et 
al. 2008). “A view is a projection of the enterprise architecture model that is meaningful 
to one or more system stakeholders” (DoD 2007). Architecture frameworks aid decision 
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makers in making design ehoiees by providing elear, eomprehensive, funetional system 
deseriptions understood by all of the system stakeholders. The United States military uses 
the DoD Arehitecture Framework (DoDAF) as its standard systems architeeture 
framework. The DoDAF elassifies and organizes the development of eomplex systems to 
aid in sueeessful system design and implementation. 

a. DoD Architecture Framework (DoDAF) 

The DoDAF defines how to organize enterprise arehiteetures for U.S. 
DoD applieations. The DoDAF is a deseriptive methodology for capturing high-level 
system information using four different display formats or views. “All major DoD 
weapons and information technology system procurements are required to document their 
enterprise architectures using the view products prescribed by the DoDAF” (DoD 2007). 
Figure 4 displays the architectural view categories and their associated relationships for 
DoDAF version 1.5. 



Figure 4. DoDAF View Categories. (From; (DoD 2009)) 
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The four DoDAF view sets are (DoD 2009); 


• All View (AV): Deseribes the scope and context (vocabulary) of the 
architecture. 

• Operational View (OV): Identifies what needs to be accomplished and 
who does it. 

• Systems and services View (SV): Relates systems, services, and 
characteristics to operational needs. 

• Technical standards View (TV): Prescribes standards and conventions. 

Each view is designed to provide a specific aspect of the system 
architecture allowing a stakeholder to make informed decisions and changes. The 
DoDAF uses a shared architecture repository to provide a common language and 
continuity to the architecture development process. The DoDAF views are defined by 
Vitech within their Core Architecture Data Model (CADM), which is used to model the 
capability needs of the UV Sentry unmanned surface vessel. Figure 5 gives specific 
examples of the four views and brief examples of what they illustrate. 
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AV.1 

Overview and Summary Information 

AV-2 

Integrated Dictionary 

OV-1 

High-Level Operational Concept Graphic 

OV-2 

Operational Node Connectivity Description 

OV-3 

Operational Information Exchange Matrix 

OV-4 

Organizational Relationships Chart 

OV-5 

Operational Activity Model 

OV.6a 

Operational Rules Model 

OV.6b 

Operational State Transition Description 

OV-6C 

Operational Event-Trace Description 

OV-7 

Logical Data Model 

SV-1 

Systems Interface Description 

SV-2 

Systems Communications Description 

SV-3 

Systems-Systems Matrix 

SV-4 

Systems Functionality Description 

SV-5 

Operational Activity to Systems Function 
Traceability Matrix 

SV-6 

Systems Data Exchange Matrix 

SV-7 

Systems Performance Parameters Matrix 

SV-8 

Systems Evolution Description 

SV-9 

Systems Technology Forecast 

SV-tOa 

Systems Rules Model 

SV-lOb 

Systems State Transition Description 

SV-10C 

Systems Event-Trace Description 

SV-11 

Physical Schema 

TV-1 

Technical Standards Profile 

TV-2 

Technical Standards Forecast 


Figure 5. DoDAF vl.5 Views Examples. (From; (DoD 2007)) 


b. Naval Architecture Elements Reference Guide (NAERG) 

The Naval Architecture Elements Reference Guide (NAERG) and the 
DODAE provide the standard for defining DoD system architectures. While the DoDAE 
aids in organizing the system architecture, the NAERG provides the standard terminology 
to be used when describing system architecture elements. Elsing standard terminology in 
system architectures enables the stakeholders to properly communicate, track. 
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standardize, and refine DoD arehitectures and their elements. Standardization of 
arehitecture development terms and teehniques minimizes efforts in the integration of 
elements within a system, or SoS arehiteeture. The NAERG provides a repository of 
information eritieal to architecture framework development and programmatic and 
acquisition activities. The NAERG includes the Common Systems Eunction Eist (CSEE), 
Common Operational Activities Eist (COAE), Common Information Element Eist 
(CIEE), Common Operational Node Eist (CONE), Common System Node List (CSNL), 
and Common System List (CSL). 

c. Universal Naval Task List (UNTL) 

The Universal Naval Task List (UNTL) is a combination of the Navy 
Tactical Task List (NTTL) and the Marine Corps Task List (MCTL). It lists tasks that can 
be performed by naval forces and describes the measures of performance that can be 
implemented to evaluate individual task performance. The UNTL is used in conjunction 
with DoD’s Universal Joint Task List (UJTL) that contains a hierarchy of joint tasks in 
support of joint service missions. Both provide a common language baseline and 
operational reference system for commanders, operators, and trainers. Additionally, both 
can be used by system designers as an excellent source of requirements, capabilities, and 
combat activities required to perform military missions. Joint Mission Essential Tasks 
(JMET) and Naval Mission Essential Tasks (NMET) are activities that operational 
commanders deem critical to mission accomplishment. Both are listed in the Joint 
Mission Essential Task List (JMETL) and Naval Mission Essential Task List (NMETL), 
respectively, and are chosen from the UJTL or UNTL. 

Although the UJTL and UNTL are intended to be used by trainers and 
operational commanders, they provide system designers and architects with a valuable 
tool in determining capability needs through exploration of required missions and tasks. 
The lists are used to determine mission requirements by exploring the operations that 
military platforms are expected to perform. The missions are then used to determine the 
sets of activities and capabilities required to perform the missions. Tracing operations to 
the task level provides designers with individual activities that must be accomplished by 


18 



a military entity to accomplish the assigned mission. These tasks can aid the system 
architect in building comprehensive functional and physical architectures. This process 
also provides designers with operationally relevant terminology and measures of 
effectiveness valuable to system development. This allows system engineers and 
architects to design a military system using warhghter terminology, focus, and measures. 
Using warfighter terminology and mission-derived capability needs allow system 
designers to better communicate with the DoD customer and to provide them with a more 
comprehensive product. 

5. Design Reference Mission (DRM) 

The DRM is a documentation exercise used as a tool to aid in the systems 
engineering requirements definition process (Skolnick and Wilkins 2000, 208-216). The 
first step in the concept development process is to fully define the requirements of the 
desired system. This step ensures the designer effectively defines the problem without a 
preconceived notion of a particular solution. The DRM establishes the baseline for 
subsequent systems engineering activities. It establishes the groundwork for the 
generation of requirements, refining problem definition, development of concepts, 
analysis of alternatives, and test and evaluation (Skolnick and Wilkins 2000, 208-216). 
The concept is used to establish a warfighting CONOPS for a system and to describe the 
operational activities necessary to achieve desired system capabilities. 

Composing a DRM begins with understanding the warfighter’s operational 
concept. This understanding is then used to build a simulated environment in which 
system concept alternatives are expected to perform. The projected operational 
environment (POE) is the environment in which the system is expected to operate and 
provides the context within which tasks will be performed in support of the mission. 
Once in a mission-executable environment, the capabilities necessary to complete that 
mission can be exercised. When designing a reference mission, it is important to 
understand the environment surrounding the mission analysis. A scenario includes a goal, 
a deployment of systems, a physical environment in which the mission takes place or is 
executed, and whatever changes the environment will undergo as the scenario progresses. 


19 



“The DRM defines the speeifie projected threat and operating environment baseline for a 
given force element..(Skolnick and Wilkins 2000, 208-216). 

Operational Situations (OPSITS) are unique instances of a DRM where the 
variables can change. They are identified based on needs requirements and are meant to 
feature selected operational characteristics, or combinations thereof, in operationally 
viable combat environments. OPSITS should be specifically developed to stress selected 
system design attributes and support functional and performance tradeoff analysis 
(Skolnick and Wilkins 2000, 208-216). Educated assumptions are made about the 
operational environment, required logistics, deployment, and mission timeline. The 
systems engineer must determine which OPSITS are necessary and ensure they are 
validated by subject matter experts (SMEs). 

E. SCOPE 

The overall UV Sentry development process in Eigure 1 is broad enough to cover 
the entire system development. The scope of this thesis is limited to the model-based 
systems engineering and related trade off assessments for a UV Sentry autonomous 
surface craft designed to serve in a force protection mission. The methods and tools 
provided present a baseline process for developing the USV systems architecture and 
model-based tools for concept exploration and tradeoff analysis. The analysis in this 
thesis does not reflect a finalized conceptual design. The analysis gives a clear picture of 
the process in a “real world” design application. 

The primary focus of this thesis is to provide a systems architecture and 
conceptual design footing for the UV Sentry SoS unmanned surface vessel (USV) design 
team. It is to be used as a guideline for system designers and architects and employed 
when constructing their system-specific MBSE architecture and design methodology. 
This thesis offers a number of tools and techniques for designers to build a 
comprehensive conceptual design leading to a successful system design. It focuses on the 
conceptual design of a USV to provide explicit support to the UV Sentry SoS program 
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but the methods, tools, and teehniques deseribed are not limited to the design of a USV. 
The process described herein can easily be used in support of any system or process 
design. 

F. METHODOLOGY 

Model-based design uses mathematical models and visual aids to guide designers 
and architects in the development, design, and testing of systems. MBSE is particularly 
useful for designing large, complex, or highly integrated systems or systems of systems. 
MBSE significantly differs from traditional design by using models to simulate system 
performance to appropriately augment the use of expensive and time-consuming 
prototypes or teams of engineers making multiple performance calculations for each 
operational scenario. This approach provides system designers with fast, flexible, and 
efficient tools that can be used throughout system development and test and evaluation. 

The process begins by identifying the system (or type of system) to be 
implemented and finding, or building, a model to simulate the “real-world” system 
performance and interactions. Once the model is determined to be acceptable, it can be 
used to analyze predicted, dynamic system performance and synthesized to test system 
requirements, specifications, and potential shortcomings. Models can be used early in 
system development providing the means for system designers and stakeholders to 
explore design concepts by simulating a proposed system point design in its expected 
operational environment. This allows designers to test ideas without spending large 
amounts of money on prototypes and physical testing. MBSE also builds a common 
design environment facilitating effective communication between system stakeholders. 
Using models early in the development process allows designers to identify and correct 
design issues before they become too costly to address. 

Eigure 6 illustrates the simplified model configuration used in the MBSE SoS 
development process. The SoS architecting model, ship synthesis model, and MCDM 
tool are each used to build the conceptual design. The ship synthesis model predicts the 
physical performance of the system. The architecture model includes the framework and 
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organizational structure for the operational, functional, and physical models. The MCDM 
tool provides the means for system developers to explore conceptual designs and analyze 
design tradeoffs. 



Figure 6. MBSE Method. 


Constructing the system architecture for the UV Sentry USV is a cooperative 
process headed by the system arehitect that must include all system and process 
stakeholders. The architeet must eontinually work with the stakeholders to iteratively 
define the system structure, resolve ambiguity, reduce complexity, and focus creativity 
toward a problem solution. The architect must direct the transformation of the system 
from conception to realization by using a series of SE and arehitecture development tools 
and techniques. Each step in the process further develops the arehiteeture model 
increasing system clarity and fidelity with each design iteration. Arehitecting principles, 
model-based methods, SE tools, and management activities are used to define, develop, 
integrate, and evolve the functional and physical models. The architecture model exists to 
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develop a well-defined system that meets the desired system effeetiveness. The system 
arehiteeture provides the means to model, simulate, engineer, display, and test coneepts. 

Defining the arehiteeture model strueture starts with the transformation of 
operational mission eapability elements into a set of operational aetivity elements. The 
ereation of the arehiteeture model (the fundamental structure of a system) is the key step 
in the transformation of loose requirements to a well-structured definition for system 
development. In the most basic terms, design can be defined as a process to determine 
form based on function. Creating various concepts through a design process allows 
engineers to explore the solution space, applying creativity to the development of 
concepts. The determination of how well each concept accomplishes functional 
characteristics, as manifested in the physical form proposed, becomes the basis for 
selection of the best concept solution. This conceptual design process is a critical step in 
transforming capability needs to physical function. This step allows system designers to 
explore design alternatives and ultimately select the design that best meets the needs of 
the stakeholders. 

Building a model-based method using the architecture products alone does not 
provide adequate information for a smooth transition from system development to a more 
traditional systems engineering process. An Element Relationship Attribute (ERA) 
structure is a more rigorous method needed to define the architecture model, and provide 
a structure upon which to make reasoned decisions. The ERA based architecture 
definition language handles the syntax and semantics needed for creation of the base 
architecture model and derived products. This includes the ability to enact an iterative 
process of discovery in meeting emerging capability needs as they arise. 

Next, operational activity elements are related to functional, non-functional 
(constraints) elements, requirement (functional achievement metrics) elements, and other 
elements. This leads to the eventual specification of component elements that are used to 
create the finished product. This structure provides the basis necessary to facilitate 
concept trade-off studies of possible alternatives by explicitly recording the 
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interconnections among elements. The method allows stakeholders to focus future 
research efforts and prevent the expenditure of vast resources into non-critical or easily 
countered areas. 

For this thesis, input variables are treated as both uncertain and deterministic to 
create models based on probability of occurrence. This facilitates more exploratory trade¬ 
off studies showing probabilities of achieving outcomes instead of hard boundaries for 
trade-off. The variables are defined by distributions of possible outcomes, rather than 
these fixed points, since there is uncertainty associated with their achievement, either due 
to technology limits or perhaps funding levels need to get them to the limits desired in the 
time frame desired. This can provide valuable information for technology planning and 
maturation expectations in the technology development phases of product acquisition. 
This method also allows stakeholders to tailor the model as the program evolves to 
account for things such as technology maturation, cost growth, risk assumption, or 
requirements creep. Specifically, this will be used to determine where to focus 
technology investments, and what technology development goal is required to achieve the 
desired outcome. 

The systems engineering and architecture development model was implemented 
using the Vitech CORE systems engineering repository software package. The ship 
synthesis model is a Microsoft Excel-based ship resistance tool specifically implemented 
for prismatic planning hulls. Optimal design space exploration was accomplished using 
Design of Experiments (DOE) and Response Surface Methods (RSM) from ship 
synthesis model data. This was accomplished using the SAS JMP statistical software 
package. JMP provided visualization of the model outcomes and the means to accomplish 
the quantitative trade-off of specific design variables in the context of system measures of 
performance (MOP). 

G. APPLICATION 

The methodology described in this chapter is applied in the following chapters to 
apply a systems and mechanical engineering approach to develop an executable system 
architecture model for the UV Sentry System’s autonomous surface craft. The MBSE 
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approach is expanded to a model-based systems engineering eoneept that uses modeling 
in both the eoneeptual design and arehiteeture development proeess of system 
development. The arehiteeture model and MCDM tool developed in this thesis provides 
UV Sentry stakeholders with the means to eonduet and prioritize system-level mission 
and teehnieal assessment studies in developing the framework for the eoneeptual design. 
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II. UNMANNED SYSTEMS 


A. INTRODUCTION 

Unmanned systems are currently used in a variety of military applications around 
the world to perform tasks that are dirty, dull, and dangerous for soldiers, sailors, and 
airmen to perform. They span all domains including air, land, surface, and subsurface 
applications. 

B. OVERVIEW OF CURRENT STATE 

Unmanned systems are intended to provide significant reductions in manpower 
and risk to personnel while providing persistent accomplishment of mission tasks. They 
are designed for a number of security and military applications with a multitude of 
emerging capacities currently being developed. Traditional roles for unmanned vehicles 
focus on the collection and dissemination of ISR information. Future unmanned system 
capabilities include autonomy, targeting, offensive and defensive fire, and multi-mission 
applications. 

Unmanned vehicles can perform missions in areas deemed unsafe or politically 
sensitive for human operators. They can be deployed from a variety of platforms and 
maintained on station as long as fuel and the operational environment dictate. UVs are 
currently in use all over the world, with particular emphasis on their use in support of 
operations in Iraq and Afghanistan. Their use has grown significantly in recent years, 
with increased warfighter demand expected in the near future as more emphasis is placed 
on cost-effective ways to provide safety and security. 

C. PROBUEM WITH CURRENT STATE 

Unmanned systems are typically designed and built to perform a single mission 
and require a robust support element including numerous operators and maintainers. The 
personnel required to control, launch, recover, fuel, and maintain unmanned vehicles 
often rivals that of manned systems. Automation of unmanned system functions would 
ease the requirement for support personnel providing significant savings over traditional 
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UxV systems. Along with automation, future unmanned systems must shorten the time it 
takes to refuel and return to station. Autonomous refueling eapability coupled with a 
forward-deployed refueling base permits unmanned vehicles to remain on station longer 
by shortening refueling transit times. Ultimately, this will further reduce cost by requiring 
fewer vehicles to perform a given mission by reducing the frequency of on-station reliefs. 

Communication and data transfer capabilities pose another significant issue in 
UxV operation and development, particularly with USVs. Current systems are greatly 
hampered by the highly restrictive limits of line-of-site (LOS) and over-the-horizon 
(OTH) tactical links. Military and DoD-commercial communication satellites are 
currently operating at their maximum bandwidth capacity. Unmanned system 
communication requirements significantly strain DoD-dedicated satellite assets. Today’s 
USVs typically require human operators to maintain LOS connectivity with the UVs they 
are controlling. The enormous bandwidth and the high rate of data transfer required are 
far too hefty for current satellite capabilities. Having to maintain LOS connectivity places 
the UV closer to the operator increasing the operator’s chance of harm. USV automation 
provides internal control of system functions resulting in a vast reduction of data 
bandwidth required for operation. This allows the vehicle to operate farther from control 
personnel, placing the human out of harm’s way. 

The lack of system collaboration is another significant shortfall in the 
development of UxV systems. There are a number of current UxV research and 
development (R&D) and acquisition programs in existence but far less coordination and 
capability sharing between organizations and their systems. This lack of coordination is a 
challenge to designers of future multi-mission, multi-domain UxV SoS. Future UxV 
capabilities must incorporate a fully coordinated, multi-domain, multi-mission SoS to 
achieve the full benefits of unmanned systems. This system of unmanned systems shall 
cover all domains and function autonomously within its network-centric area of 
operations. The systems components shall be able to operate individually or collectively 
to accomplish an assigned mission. This SoS arrangement maximizes the effectiveness as 
well as the combat and operational survivability of the system as a whole. If an individual 
unit is disabled or reassigned, the system autonomously adjusts and assigns other assets 
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to perform the re-assigned unit’s tasks in a prioritized order. An integrated network of 
multiple unmanned vehieles and external sensors can effectively span large geographical 
areas greatly improving situational awareness and mission coverage. 

D. UV SENTRY 

1. Overview 

The UV Sentry SoS is an Office of Naval Research (ONR) led initiative 
investigating the use of unmanned vehicles for force protection. The project is aimed at 
preventing terrorism and piracy in the maritime domain using a coordinated assortment of 
autonomously controlled assets including air, surface, and subsurface vehicles. The 
initiative leverages a consortium of DoD, governmental department, industry, and 
academic participants including warfare centers, research laboratories, and the Naval 
Postgraduate School. The proposed system shall, at a minimum, be capable of searching 
for and identifying potential threats from an adequate reaction distance, discerning hostile 
from non-hostile entities, interdicting hostile or non-compliant units, and conducting 
deterrence and, if necessary, threat neutralization actions. 

A key near-term project goal is to develop functional architectures for security 
missions that support the detection and identification of threats to stationary marine 
platforms. Figure 7 illustrates an example of the UV Sentry SoS used in sea base defense 
mission. This example includes mine warfare (MIW), anti-submarine warfare (ASW), 
and surface warfare (SUW) support missions. The stationary high-value asset (HVA) 
protection mission was selected as a good starting point due to its importance, relevance, 
and straightforwardness. 
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Figure 7. UV Sentry in Defense of a Sea Base. (From: (Whitcomb et al. 2008)) 

2. Need 

Sea based assets are highly vulnerable to attack from a number of adversaries 
with the capability to inflict grave damage. The asymmetrical nature of terrorist attacks 
and the large coverage areas to protect make the protecting sea based assets particularly 
challenging. Stationary HVAs, such as ocean oil drilling platforms, are particularly 
vulnerable and must be protected from a multitude of potential threats including 
disguised surface units, aerial attacks, and undersea assaults. In addition, the relatively 
close proximity of most stationary HVA to shore makes their protection an even larger 
challenge due the rapid identification, interdiction, and reaction times required. 

Manned units spend countless hours patrolling their allocated security area 
attempting to keep potential hostile entities at a safe distance from their assigned HVA. 
This task requires manned operators to remain alert and diligent despite the dullness of 
the mission. In addition, the maritime security mission typically requires a large number 
of assigned personnel to provide full coverage over a large security area. The 
complement of manpower required to accomplish the mission depends on the size of the 
security area, the importance of the HVA (including financially and politically), the 
probability and severity of potential attack, the nature of the threat, and the availability of 
protection force assets. In addition to operational staff, a cadre of support personnel must 
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be included for non-operational tasks such as: logistics, maintenance, training, and 
habitability. The large number of required personnel places huge financial burdens on the 
U.S. and partner nation security forces. 

Protection of HVAs must be accomplished without placing personnel, or other 
valuable assets, in harm’s way. Employment of manned vessels for maritime security 
places sailors and their ship in potential danger. The surreptitious nature of the threat 
often compels security personnel to come in close contact with potentially hostile entities. 
Coming within close proximity of a capable and determined enemy places U.S. or partner 
nation personnel in tremendous danger. The loss of personnel or valuable national assets, 
such as U.S. Navy warships, is socially, politically, and financially deplorable. COCOMs 
are committed to accomplishing mission tasks while maintaining their assets as far from 
harm as possible. 

The diverse nature of potential threats requires assets to search and protect a large 
geographical area in multiple physical domains (air, surface, and subsurface). This 
necessitates the need for a distributed, multi-domain, integrated SoS with elements that 
operate in tandem to protect the HVA. Use of manned assets to meet this need is not only 
costly but can be dangerous when friendly assets come within close proximity of one 
another. The use of manned assets also creates integration and communication challenges 
that can easily result in loss of situational awareness resulting in lapses in security and 
potential harm to the HVA. 

The UV Sentry SoS offers the autonomous, multi-domain, distributed, integrated, 
force-multiplying effect required to meet future HVA maritime security needs. The 
unmanned nature of the SoS maintains a high, persistent level of security while 
maintaining safe distance for human operators and valuable assets. UV Sentry also 
provides a cost-effective alternative to using a large number of manned assets. 

3. Vision/Goal 

The goal of the UV Sentry SoS is to provide persistent and effective defense of 
naval and maritime assets. The SoS must sense, identify, interdict, and deter current and 
projected threats to sea based assets. Figure 8 illustrates the UV Sentry concept of 
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operations in an OV-1 view. The view portrays a SoS of unmanned heterogeneous 
maritime vehieles whieh operates autonomously and eooperatively for exeeution of many 
different missions (Whiteomb et al. 2008). 


Oil Platform Defense Missile Defense 



Anti-Surface Warfare 


Figure 8. UV Sentry OV-1. (After: (Whitcomb et al. 2008)) 

The UV Sentry vision includes the following capabilities: 

• Provide situational awareness around sea-based assets at distances 
sufficient to neutralize detected threats 

• Perform ISR alert function and will, when appropriate, monitor and 
engage threats 

• Operate and manage system assets autonomously, including autonomous 
refueling/recharging to minimize human supervision/control/support 

• Process data autonomously to provide a knowledge base for the 
operational forces and commanders so that they can make informed decisions 

• Deploy non-lethal and lethal weapons under human command and control 
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E. AUTONOMOUS SURFACE CRAFT 


1. Overview 

The following section provides a general overview of current USV state-of-the- 
art. This section provides a baseline understanding of USV mission areas, classes, craft 
type, component areas, and technical challenges. 

2. Mission Areas 

The mission areas that are relevant to the USV are: mine countermeasures; anti¬ 
submarine warfare; maritime security; surface warfare; special operations forces support; 
electronic warfare; and maritime interdiction operation support. These mission areas are 
described below and are obtained from (PEO LMW 2007). 

a. Mine Countermeasures (MCM) 

“MCM mission requirements are driven by the Fleet’s need to rapidly 
establish large, safe operating areas, transit routes (Q-routes) and transit lanes” (PEO 
EMW 2007). MCM mission areas can range in size from 100 to 900 nm , covering 
waters all the way to the shore. The objective of the MCM mission is to enable safe Fleet 
Operating Areas clear of mines. 

The traditional MCM functions are: detect; classify; localize; identify; and 
neutralize. Each of these functions is required to confront the threat that mines pose 
against Fleet platforms. Additionally, the following MCM behaviors encompass the 
MCM mission: reconnaissance; search; hunting; breaching; clearance or clearing 
objective; sweeping; jamming; and signature. 

USVs, along with UUVs, are particularly well suited for the “dirty - dull - 
dangerous” tasks that MCM entails. They provide persistence, which permits significant 
mine hunting and sweeping coverage at lower cost by multiplying the effectiveness of 
supporting or dedicated platforms. Additionally, they provide the potential for supporting 
an MCM capability on platforms not traditionally assigned a mine warfare mission. 
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b. Anti-Submarine Warfare (ASW) 

“It is vitally important that the U.S. Navy be able to achieve and maintain 
access to all the world’s littorals at the times and places of its choosing” (PEO LMW 
2007). There are three major categories of ASW as identified by Task Force ASW: 
“Hold at Risk,” “Maritime Shield,” and “Protected Passage.” “Hold at Risk” observes 
submarines of interest as they leave a port or in transit through a chokepoint. “Maritime 
Shield” involves ensuring that a large strike group is not threatened by enemy 
submarines. “Protected Passage” entails establishing a safe path, free of enemy 
submarines, for a large strike group. 

USVs are able to enhance the ASW mission, specifically, the capabilities 
of “Maritime Shield” and “Protected Passage.” Most of the submarine threats in the 
future will be from numerous smaller conventional vessels that are able to operate in 
shallower waters than U.S. Navy submarines can operate. The objective is to utilize 
USVs to “patrol, detect, track, hand off, or engage” (PEO EMW 2007) enemy 
submarines. The use of USVs for ASW frees up manned platforms to focus on other 
mission areas and also enhances situational awareness by extending the sensor reach of 
the unmanned platforms. 

c. Maritime Security (MS) 

“MS consists of securing U.S. or allied domestic ports, and protecting ship 
and maritime infrastructure (piers, docks, anchorages, warehouses) at home and abroad 
against the spectrum of threats from conventional attack to special warfare [and] 
specifically target terrorist attacks” (PEO EMW 2007). The key to a successful MS 
mission is the ability to act on information through good situational awareness. 
Consequently, Intelligence, Surveillance and Reconnaissance (ISR) are of utmost 
importance to the accomplishment of this mission. The MS mission is enhanced by the 
unique capabilities of the USV. 

USVs are able to function effectively away from the home platform and in 
shallow water to enhance sensor information while not putting manned platforms in 
jeopardy. Furthermore, USVs can operate in areas that are considered to be too 
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hazardous to manned vessels (both environmentally and militarily). MS system eoneepts 
inelude “sensing, signal proeessing (for deteetion, elassifieation, loealization, and 
traeking), deeision making (man-in-loop, semi-autonomous, or autonomous), and 
response” (PEO LMW 2007). 

There are seven possible MS USV missions identified. These missions 
inelude: strategie and taetieal intelligenee eolleetion; ehemieal, biologieal, nuelear, 
radiologieal and explosive deteetion and loealization; eoastal and harbor monitoring; 
deployment of remote sensors; speeialized mapping and objeet deteetion and loealization; 
non-lethal and lethal threat deterrenee; and riverine operations (e.g., eivilian boat traffie 
monitoring). The multi-funetionality of USVs and their ability to be deployed from 
various platforms augment the ISR of U.S. Forees, improving mission effeetiveness, 

d. Surface Warfare (SUW) 

The SUW mission is very similar to the MS mission, however, the SUW 
mission also eneompasses the threats posed in more open waters and littoral regions, and 
the eraft required is more robust. The objeetive of the USV SUW mission is to “provide 
the ability to engage targets through the use of lethal and/or non-lethal weapons while 
proteeting or keeping manned platforms out of harm’s way” (PEO LMW 2007). The key 
eapability for the suceess of the SUW mission is for the USV to be eonfigurable to 
various payloads as well as the ability to be outfitted with various sensors and weapons. 

e. Special Operations Forces (SOF) Support 

“SOF units require support for eondueting missions involving 
uneonventional warfare, eounter-terrorism, reeonnaissanee, direet aetion and foreign 
internal defense, among others” (PEO LMW 2007). SOF is usually used when the goal is 
to disrupt by “hit and run” and disruption, instead of the eonventional “foree on foree” 
warfare. SOF support USVs will typieally be required to operate in eoastal and riverine 
environments. 

The main purposes for using USVs in support of the SOF mission are to 
eomplement ISR and to provide transportation and logistie support. The inherent 
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versatility of the USV increases SOF mission effectiveness and improves situational 
awareness and SOF logistics through sensor deployment and supply delivery. 

/, Electronic Warfare (EW) 

The objective of the EW mission is “to use US Vs to provide a means of 
deception, jamming, and warning of electronic attack. US Vs can provide a persistent and 
effective capability with significant range, endurance, and capacity for large payloads and 
power generation” (PEO EMW 2007). Eunctions of the EW mission are often dependent 
on ISR. The USV EW mission encompasses: creating false target deception; acting as a 
data repeater between large strike groups; and extending radar jamming. 

g. Maritime Interdiction Operations (MIO) Support 

“MIO is traditionally defined as activities by naval forces to diver, disrupt, 
delay, or destroy the enemy’s military potential before it can be used effectively against 
friendly forces” (PEO EMW 2007). MIO is inherently a manned mission; thusly, the 
USV MIO support augments the mission through enhancing situational awareness. The 
ideal use of a USV for MIO support missions is to provide ISR on a target vessel before a 
boarding or interrogation. Due to the importance of accurate data and the specialized 
nature of this mission, emphasis is placed heavily on sensors. 

3. Vehicle Classes 

The Navy Unmanned Surface Vehicle (USV) Master Plan (PEO EMW 2007) 
organizes US Vs into four classes based on analysis considering USV mission 
requirements and naval architecture characteristics such as stability, payload, speed, and 
endurance. Class selection included a weighted scale of USV critical attributes including 
US Navy ship transportability and minimization of required accommodation 
modifications. Although these classes are near-term, solution-based USV alternatives, 
they are briefly described to provide the reader with a functionality baseline and a 
reference for current design concerns. 
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a. X-Class 

The X-Class is small, special purpose craft intended to be inexpensive and 
relatively expendable. Vessel length is 3 meters or less and expected to serve in SOF or 
MIO support missions. They have limited endurance, payload, and seakeeping abilities 
and are not standardized for modularity. Figure 9 displays a few examples of X-class 
vessels. 



Figure 9. USV X-Class. (From; (PEO LMW 2007)) 
b. Harbor Class 

The Harbor Class USVs use a 7 meter RIB as the hull platform to conform 
with current U.S. Navy ship transportability and accommodation capabilities. The craft 
has moderate endurance capability and is expected to perform ISR and MS missions. This 
class is expected to retain the ability for manned operation. Figure 10 displays an 
example of a Harbor class vessel. 
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Figure 10. USV Harbor Class. (From; (PEO LMW 2007)) 


c. Snorkeler Class 

The Snorkeler Class USV is a 7-meter semi-submersible craft, with only 
its snorkel above the surface during operation, providing a stable platform in high sea 
states. This craft is expected to perform MCM and ASW missions due to its ability to pull 
a tow body and its stability and endurance characteristics. Figure 11 displays an example 
of a Snorkeler class craft. 


38 











!> of sopporting: 


Snorkeler Class 


7M Somi- 
Submoisiblo 
1S« knots 


viS R 

J^pia 


HCM Dolbfory 

ASWNbMMmoShioKI 

SUWfTotpodo) 


24 bonrtyi 
onduronco 


Towod 


Figure 11. USV Snorkeler Class. (From; (PEO LMW 2007)) 
d. Fleet Class 

The Fleet Class USV is an 11-meter planing or semi-planing craft 
providing relatively high speed, extended endurance, and moderate payload capacity. It is 
expected to perform MCM, ASW, SUW, or EW missions and anticipated to retain the 
ability for manned operation. The vessel has a modular design with the ability to swap 
mission modules in less than 24 hours. Eigure 12 displays an example of a Fleet class 
vessel. 
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Figure 12. USV Fleet Class. (From: (PEG LMW 2007)) 


4. Craft Types 

a. Introduction 

The Navy Unmanned Surface Vehicle (USV) Master Plan (PEG LMW 
2007) also classifies USVs by hull type. These potential alternatives were based on the 
interface of the vehicle with the sea surface. 

b. Semi-submersible Craft 

The semi-submersible craft operates with most of its volume below the sea 
surface exhibiting lower drag and platform motion than conventional hull designs. This 
results in significantly reduced drag allowing for a larger percentage of the craft’s power 
to be available for other purposes. The craft is less affected by sea state, giving it a larger 
operational weather window and better sensor and payload stabilization. The platform is 
very stable making deployment and retrieval of payloads easier. The craft has a very 
small radar cross section and a low visual signature making it very stealthy. Craft speed is 
limited to approximately 25 knots for a 7m craft and is more costly than conventional 
hull designs (PEG LMW 2007). 
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c. 


Conventional Planing Hull Craft 


There are a variety of conventional planing the V-Hull, Modified V, and 
M-Hulls. The V-hull is the most common, providing relatively high speeds and a number 
of positive performance characteristics such as payload capacity and endurance. Planing 
hulls are more sensitive to load distribution (especially when planing) and may show less 
towing efficiency than other craft types of its size. At lower speeds (when not in planing 
mode), these hulls perform similarly to normal full-displacement craft and may be less 
stable especially in a seaway or when at rest. At high speeds, the hull may experience sea 
slamming especially in higher sea states or confused seas. Planing craft offer a relatively 
high payload fraction and can be of low complexity and less expensive than many other 
hull forms (PEO LMW 2007). 

d. Semi-planing Hull Craft 

The Semi-Planing hull exhibits lower drag and better moderate speed 
performance in higher sea states than most conventional planing hulls. The craft typically 
show less sensitivity to sea state providing a more stable platform for sensors or towing. 
They can operate at relatively high speeds and tend to be more efficient across the entire 
array of speeds than most conventional planing hulls. The hull form tends to be more 
slender with a higher length-to-beam ratio and lower payload fraction than similarly sized 
conventional planing hulls (PEO EMW 2007). 

e. Hydrofoils 

Hydrofoils provide the lowest drag and best sea-keeping of all the hull 
forms making them very stable, especially in moderate to low sea states. They are 
typically faster than the other hull types due to their very low wetted surface area (when 
at sufficient speeds), often capable of achieving sustained speeds greater than 40 knots. 
Hydrofoils are not well suited for towing and are typically more complex than other hull 
forms making them more costly to design, test, build, and maintain (PEO EMW 2007). 
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/. Other 

There are a number of other conventional and non-conventional craft types 
that are feasible for USV design. These include pure (full) displacement, Small 
Waterplane Area Twin Hull (SWATH), wave piercing, and multi-hulls (among others). 
Each of these tends to be appropriate for very specific capability needs and are not 
typically used in current USV design. Many of these have a tendency to cost more to 
design, build, and maintain than like craft and are can be more difficult to transport and 
accommodate. Apart from the full displacement craft, they are typically more sensitive to 
weight changes and less stable than other platforms making them unsuitable for most 
towing and sensor operations (PEO EMW 2007). 

5. Component Areas 

a. Introduction 

The below component areas are essential to the successful completion of 
all USV missions and are identified in (PEO EMW 2007). 

b. Hull 

The hull is obviously the most important component of the USV, or of any 
water vessel for that matter. As discussed earlier, there are many different types of hull 
design that can be used for the USV, from conventional planning hulls, to hydrofoils. 
The hull selection is dependent on the mission the USV will be performing. The size of 
the hull is also a function of the mission type. Typically, USV hull lengths vary from 15 
to 40 feet. 


c. Ballast 

The type of ballast used is dependent on the selection of the USV hull and 
therefore the mission type. In general, ballast affects a vessels center of gravity and draft. 
Ballast is particularly important to the semi-submersible hull form because it uses a 
ballasting mechanism to modify its position with respect to the water line. 
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d. Energy 

Auxiliary power for the eleetronic eomponents aboard the USV is 
typieally generated by battery or generator or a eombination of both. The auxiliary 
power must be suffieient enough to provide energy for all eleetronic components on 
board, such as, actuators for steering, sensors, and communications. 

e. Navigation, Guidance, and Control 

Navigation, guidance, and control are the “brains” of the USV. Without 
these elements the USV is simply a boat dead in the water. The essential elements of 
navigation, guidance, and control are accurate sensors and effective actuators. The 
sensors that are most important to the accurate navigation and guidance of a USV are the 
Global Positioning Satellite (GPS) receiver and a radar system. The GPS receiver can 
interface with a Digital Nautical Chart (DNC) that provides information on permanent 
obstacles (coastline, piers, buoys, etc.). The standard marine radar (Furuno) is capable of 
providing adequate data to account for obstacles in motion, as well as correlating 
information from the DNC to enhance positional location. Sensitive actuators are 
required to control the USV’s steering and throttle based on the environmental picture 
provided by the sensors. Control modes can either be: “manual,” where the actuators are 
actually fully integrated into the USV; “drive-by-wire,” where the helm and throttle have 
actuators attached to them; and, computer operation, where the USV maneuvers based 
only on information stored in onboard computer. Additionally, the onboard computer 
will have to take into account the 1972 International Regulations for Preventing 
Collisions at Sea (USCG 1972). 

/. Communications 

The USV must be able to effectively communicate information back to the 
host platform or possibly other US Vs through a network. Additionally, effective 
communications is required to receive updated instructions. Communication is usually 
established through line-of-sight (LOS), over-the-horizon (OTH), through a network of 
USVs, or other relaying assets. A dedicated and hardened communications suite is 

required to ensure that information can always be relayed to and from the USV. 
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g. Propulsion 

The propulsion system of the USV must provide enough motive foree to 
meet the demands of the specified mission. Propulsion must be adequate enough to 
optimize maneuverability in various sea states. Additionally, propulsion for full payloads 
as well as towing must be taken into account. Propulsion can be supplied by either jet 
drive or propellers. 

h. Masts 

The mast of the USV must be capable of mounting numerous sensors and 
communication devices. A key characteristic of the USV mast is modularity, in the sense 
that the mast can be outfitted to meet the needs of different missions. 

i. Auto Launch and Recovery 

USV auto launch and recovery requires both organic docking components 
and an off-platform docking station. The host platform will to be outfitted to 
accommodate for this function. 

6. Technical Challenges 

a. Introduction 

There are numerous technical challenges that the USV program is 

confronted with. The following technical challenges as presented in (PEO LMW 2007) 
will be discussed; autonomy, obstacle and collision avoidance; threat avoidance; 
automated target recognition (ATR); autonomous deployment and retrieval of untethered 
systems; and common control. Each of these areas presents unique challenges that must 
be addressed individually. USV technology will develop in stages in an evolutionary 
process. Initially, the USV will be run “manually,” or in constant communication with 
the host platform where decisions are made for the USV. The next step is “semi¬ 
automatic,” where the USV will be in intermittent contact with the human controllers for 
important choices. Einally, the USV will be “automatic,” where it will perform its 
mission free from human contact, only communicating when mission needs dictate. 
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b. Autonomy 

The issue of autonomy is eertainly not one that is unique to the USV 
mission. Autonomy is the overarehing ability that makes all unmanned vehieles unique 
in their ability to aet free of human intervention. An autonomous USV provides many 
benefits, the two most important being that they enhanee situational awareness by 
extending sensor reaeh as well as make it possible to reduee manning requirements. 
There are different levels of autonomy that are assoeiated with the USV, from 
autonomous maneuvering to autonomous deployment of sensors. To overeome the 
teehnieal ehallenges of aehieving full autonomy, mueh researeh and advanees must be 
made in the fields of artifieial intelligenee, algorithms, and smart sensors. 

c. Obstacle and Collision Avoidance 

There are ehallenges assoeiated with developing a USV that is able to 
avoid a number of obstaeles and other extraneous objeets that appear in the environment 
that degrade mission effeetiveness. The USV must have the ability to steer elear of: the 
shoreline; other vessels; objects above the waterline (for inshore operations); underwater 
hazards (rocks, reefs, sandbars, etc.); floating debris; and, navigation aids. 

d. Threat Avoidance 

Threat avoidance is imperative to US Vs with missions operating in or near 
enemy waters. Threats to USVs can appear in numerous forms, including “ships, boats, 
aircraft, active sensor systems (e. g., radar), and to the extent possible, passive detection 
systems” (PEO LMW 2007). The challenge associated with threat avoidance is in finding 
the balance between creating a USV that can avoid threats and damage while not 
becoming too complex and expensive or degrading the original mission the USV was 
meant to perform. 


e. Automated Target Recognition (ATR) 

ATR is a necessary element of obstacle and collision avoidance. 
Additionally, ATR essential in successfully performing all USV missions (MCM, MS, 
ASW, and SUW). The challenge associated with ATR is in the development of a reliable 
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network of on board sensors that provide aeeurate data that ean be integrated and 
analyzed to create a comprehensive picture of the environment. Ideally, the optimal 
picture of the environment will be through not only numerous sensors, but also sensors of 
different types (i.e., radar, optical, infrared, etc.). The key functions of an ATR system 
are its ability to detect and identify an object accurately. Once sensors that are capable of 
processing data locally are developed and tested, the ATR challenge will be able to be 
confronted fully. 

f Autonomous Deployment and Retrieval of Untethered Systems 

Autonomous deployment and retrieval of untethered US Vs is essential 
mainly to the MIO Support mission area. This is an area that requires much more 
development. Technologies such as torpedo and missile launching platforms can be 
studied and extensively modified to develop a USV variation launching variation. 
Additionally, as overall USV technology matures, more attention can be given to meeting 
the challenge of building an affective deployment and retrieval system. 

g. Common Control 

The envisioned future of autonomous unmanned vehicles involves systems 
of systems operating in conjunction with one another to fulfill a common mission. 
Common operational functionality between UxVs in a system of systems sharing 
communication circuits and sensor networks stresses the need for an open architecture 
design to facilitate commonality amongst all UxVs. This allows for modularity to 
support multiple mission areas, ease of logistics, life cycle cost savings and directed 
technology efforts. The key to meeting this challenge “is in establishing standards for 
interoperability, communications, Hull, Mechanical, [and] Electrical (HM&E) and 
payload modularity, and Command Control, Communications, and Computers (C4) 
architecture. 

F. SUMMARY 

Chapter II provides a general overview of current USV state-of-the-art including 
mission areas, classes, craft type, component areas, and technical challenges. This 
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overview provides a suffieient knowledge base for understanding some basic concepts 
and concerns in USV design and implementation. Chapter III describes a proposed 
process to aid in the transformation of capability needs to conceptual design for the UV 
Sentry USV design tools used to build the MCDM model. 
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III. DESIGN TOOLS 


A. INTRODUCTION 

The MBSE process is intended to provide engineers with a structured method for 
system architecture and design development. The method aids the iterative SEP by 
providing engineers and architects with the framework and tools necessary to organize, 
manage, track, modify, and test system design. This chapter describes the tools and 
methods proposed for developing an architecture and designing an autonomous USV in 
support of a UV Sentry mission. It describes the elements and method for the proposed 
MBSE, architecture development and decision-making process to aid in the 
transformation of capability needs to conceptual design for the UV Sentry USV. 

B. METHOD 

The SE process depends on cooperative innovation and iterative advancements to 
yield a comprehensive system that meets customer requirements needs. The key to 
success in the conceptual design lies in the efficient and effective transformation from 
needs to functions and from functions to physical realization. This transformation can be 
very problematical in a complex system especially when using traditional engineering 
and architecture development methods. The magnitude of the capability needs, the 
elaborate technology involved, and the intricate relationships between system elements 
make designing an autonomous USV particularly difficult. It is imperative that 
stakeholders maintain traceability and control through every step of the development 
process and through each iteration of the proposed design. It is also critical to use a series 
of methods and tools that enable stakeholders to communicate ideas, analyze tradeoffs, 
and determine and agree upon optimal designs. 

The method uses several tools including a ship synthesis model, an architecture 
model, and a multi-criteria decision-making model to organize, construct, and transform 
the system design. The three models are intended to be used concurrently throughout the 
UV Sentry SEP to continually improve design comprehensiveness and fidelity. The ship 
synthesis model is the “physical” model used to predict expected performance 
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characteristics in a simulated operational environment. The arehiteeture model provides 
the strueture and organizational means to build the various views of the system 
arehiteeture. The MCDM model uses the static output data from the ship synthesis model 
to build a dynamic decision making tool to be used for eoneept exploration and trade-off 
analysis. This model enables stakeholders to visualize the feasible design spaee 
faeilitating effeetive projeet eommunieation and deeision making. The MCDM tool uses 
DOE and RSM to form a regression model from ship synthesis data to build the 
visualization and analysis tool. After making deeisions based on MCDM analysis, projeet 
stakeholders will make the appropriate updates to the arehiteeture model. Stakeholder 
decisions and new developments, sueh as eonstraints or technology maturation, may also 
force ehanges to the ship synthesis data. When this happens, the designer makes the 
appropriate ehanges and re-runs the model for the next iteration. With every step the 
design development gets eloser to solving the design problem and meeting stakeholder 
eapability needs. 

C. SHIP SYNTHESIS MODEL 

I. Overview 

The ship synthesis model is the heart of this model-based design proeess. It 
provides the “physieal world” predietions that are then eombined to build the eonceptual 
design spaee. Properly eapturing the design spaee is essential to useful and aceurate 
eoneept exploration. The old adage, “garbage in, garbage out,” applies when it eomes to 
exploring the design spaee. An inaeeurate synthesis model will yield an unsueeessful 
view of the design spaee. This skewed view eould lead designers down the wrong road in 
the system development proeess resulting in a less than optimal design. The importanee 
of choosing the appropriate ship synthesis model cannot be expressed enough. Ship 
design engineers need simple and relatively aeeurate estimation tools for predieting ship 
performanee. There are eountless models to choose from, each with their own respeetive 
eapabilities and limitations. System developers must work with stakeholders to ensure 
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system capability needs are properly defined before choosing the synthesis model, or 
models, used. Designers must also periodically re-evaluate their model(s) as iterations in 
the SE process develop. 

Ship synthesis models typically involve a combination of empirical data, 
theoretical calculations, and experience-driven rules of thumb to determine physical 
predictions. Every synthesis model uses its own assortment of inputs, assumptions, data, 
and calculations to provide its user with output information. Predicted ship properties 
such as hydrodynamic resistance or displacement are projected to find valuable second 
and third-order predictions like required power or endurance. 

2. Model Selection 

Recent developments in high-speed craft have created many different alternatives 
to the traditional full-displacement monohull craft. Hull type selection is a critical issue in 
preliminary ship design. Selection of hull form requires a great deal of investigation and 
analysis beyond the scope of this thesis. Attributes such as lifecycle cost, performance 
parameters such as speed and seakeeping, and manufacturability must be factored into the 
overall decision process when choosing a hull form. Planing monohulls are very popular 
for use in autonomous surface vessels due to their potential for high speeds compared to 
traditional monohull craft, for this reason, the planing mono hull was chosen for the ship 
synthesis portion of this thesis’ model-based design. 

The model chosen is an Excel model used by naval architects at Naval Surface 
Warfare Center (NSWC) Carderock’s Combatant Craft Division (CCD). The model uses 
data and calculations from Daniel Savitsky’s Hydrodynamic Design of Planing Hulls 
(Savitsky 1964, 71-95). The technique, often referred to as the “Savitsky method,” is a 
relatively simple but comprehensive hydrodynamic power prediction method based on 
experiments conducted on prismatic planning hulls. 

The model is only applicable for high-speed, prismatic, chine hulled vessels in the 
planning condition. At slow speeds, planing-hulled craft performance characteristics 
approach those of traditional displacement monohull vessels. Non-prismatic planning 
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hulls can be considered “prismatic” in high-speed operation mode. The model equations 
cover a variety of lift and drag forces such as normal force, friction drag, and spray drag. 

The model uses Savitsky’s “short form” calculation method due to its relative 
ease of use and comprehension. This form assumes all relevant ship forces pass through 
the center of gravity (LCG) in calculating a vessel’s resistance. Although this method is 
not as accurate as the “long form” calculation, it is perfectly acceptable as a performance 
prediction model, especially during conceptual design. 

3. Model Variables 

The ship synthesis model is comprised of a number of input and output variables 
applicable to designing relatively small, high-speed, planing craft. The model inputs 
consist of vessel physical characteristics, performance capabilities, loading parameters, 
and environmental conditions. Figure 13 displays the ship synthesis model and associated 
inputs and outputs. The inputs (and units) are: vessel length (feet), deadrise (degrees), 
LCG (%), and velocity (knots), percentage of cargo (%), percentage of fuel (%), 
headwind speed (knots), and average wave height (feet). All inputs may be manually 
typed or dialed in using a visual slider via mouse (macros enabled). Model outputs 
include (and units): required shaft horsepower (SHP), maximum duration (hrs and NM), 
estimated lightship (LBS), and maximum cargo (LBS). These values change 
automatically when the slider is moved or a new value is entered into a respective input 
cell. The model also includes a graph of required power versus speed with lines for 
minimum and maximum power depicted and labeled. The location of each set of input 
values is displayed as “input vessel” on the graph. This gives the user a visual reference 
of where an individual point design lies on a plot of required SHP vs. maximum speed. 
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Figure 13. Ship Synthesis Model. 


4. Limitations 

Speed is an important charaeteristie of both manned and unmanned sentry eraft. A 
ship’s ability to increase velocity over an adversaries’ maximum speed can be the 
difference between preventing an attack on a high value asset and allowing a threat to 
enter an exclusion zone. In general, two principal forces limit speed improvements of 
surface vessels; aerodynamic and hydrodynamic drag. Of these forces, hydrodynamic 
drag, or the resistance of the water on the wetted surface of the hull, is the primary 
hindrance of increasing speed in ship design. 

Reducing hydrodynamic drag, streamlining the wetted surface of the hull (to 
minimize turbulence), and increasing the power-to-weight ratio of the vessel are the most 
popular methods of increasing a ship’s capability to increase speed. Unlike normal 
displacement hulls, planing hulls use hydrodynamic lift in addition to hydrostatic lift or 
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buoyancy. Hydrodynamic lift raises the hull, redueing the wetted area of the hull, 
allowing the vessel to act as a hydroplane at higher speeds. At slow speeds, a planing 
eraft performs like a displaeement eraft. As speed is inereased, the relative motion 
between the hull and the passing air and water eauses a hydrodynamie lift on the bow. 
This upward foree results in the aforementioned reduetion of wetted surfaee area and a 
eorresponding reduetion in hydrodynamie drag thereby inereasing eraft speed. 

At planning speeds, a typieal planing hull generates large amounts of waves and 
spray adjacent to the hull when at planing speeds. The physieal action of the waves and 
spray are very diffieult to predict, adding a great deal of uneertainty to any planing 
model. In addition to wave making uneertainty, air resistanee plays a larger role in model 
uncertainty due to the higher speeds and hydrodynamie forees involved with planing 
eraft. Aerodynamie hull faetors have eonsiderable influenee on overall resistanee, and 
performanee, of planing craft. The model addresses wave making and air resistanee 
uneertainties by allowing the user to enter headwind speed and average wave height. 
Entering headwind and wave height information helps improve model accuraey but only 
applies loose estimations of wave and wind effects on ship performance. 

Appendages also typieally add to hull resistanee and a eorresponding reduetion of 
speed and effieiency. Bilge keels, propellers, struts, shafts, and sensors (e.g. SONAR) are 
examples of appendages that add to model uneertainty. The model ineludes a separate 
seetion that allows the user to add an estimated value for eombined vessel drag. The 
seetion eontains value cells for “new power requirements” and “new duration,” in hours, 
that eorrespond with the added drag. This enables users to aeeount for adding to or 
inereasing the size of hull appendages. The vessel drag funetion improves model utility 
but must be used with eaution as it is based on loose estimates of drag and assumes near 
ideal sea surfaee eonditions. 

Caleulating ship draft for planing hulls is diffieult aeross the full speetrum of ship 
speed. The draft of normal displaeement eraft is a function of full load displacement, 
length, beam, max seetion eoeffieient, and prismatie eoeffieient. A planing eraft at high 
speeds adds model uneertainties, due to hydrodynamie forees, to the draft estimation. 
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These uncertainties result in subsequent wetted surface and resistance calculation 
uncertainties that detract from model fidelity and add to model limitations. 

Elements such as vessel trim, shallow water bottom effects, and seaway effects 
typically effect craft performance and are not accounted for in the model. These effects 
add a greater amount of uncertainty to the model further limiting model fidelity. 
Correction factors normally required for non-prismatic (warped) hulls are also not 
accounted for in the model. The combined effects of all of the aforementioned 
uncertainty detract from model accuracy but do not discount the usefulness of the model. 
The short-form Savitsky calculation model is a good starting point to study the 
conceptual design space. There are models that estimate hull performance derived from 
the Savitsky long-form equations and more accurate calculations based on better hull 
form, appendage, and environmental condition inputs. These models are typically more 
difficult to operate and understand, often clouding the truly important design concerns. 
The designer must study all available ship synthesis models and determine which best fits 
the particular type and stage of system design. 

D. ARCHITECTURE MODEL 

1. Overview 

The Vitech CORE software analysis package was used to model the UV Sentry 
USV SoS architecture framework. CORE is a unified system architecture development 
tool that provides the means to integrate the model-based systems engineering process, 
DoDAE structure, NAERG terminology, and SoS architecture development process into 
an integrated package. This allows system architects to define, design, and build a 
complete, useful, and usable system; while lowering risk and engineering support costs 
(Vitech). This tool facilitates architecture development and ensures system elements are 
comprehensive and consistent throughout the design process. The system functions 
within CORE are derived directly from the Naval Architecture Elements Reference 
Guide (NAERG) as a predefined list of functions for combat, infrastructure, and logistics 
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(Whitcomb). Consistency and traceability are effeetively maintained due to CORE’S 
interaetive development, and eontinuous eorrelation, of operational, funetional, and 
physical architectures. 

The architeeture is divided into two behavioral domains: operational arehiteeture and 
system arehiteeture (Viteeh). Figure 14 illustrates the CORE arehiteeture development 
sehema showing the system and operational arehiteeture domains along with their 
respeetive elements and assoeiated relationships. The operational arehiteeture domain 
primarily eonsists of evaluating eoneepts and eapabilities while the system arehiteeture 
domain describes the requirements, functions, and components that make up the physieal 
design (Viteeh). 


Architecture 


System Architecture 
Domain 


Added Type ‘Service’ 

Added Service Type att^u te 


built from 






^documented by 

mterrace 

""^ns & 




> 

f 


‘"'^nnected to 
/ thru 


Specification 



Selected Classes 


Physical 

Element 

^ \ 

Interface 

Element 

Functional 

Element 

Requirement 

Element 


Figure 14. CORE Architeeture. (From: (Viteeh Corporation 2009)) 


CORE is used to eapture and eoordinate operational, funetional, and physieal 
models in order to eonstruet an integrated arehiteeture (Viteeh). The three are deseribed 
as follows: 
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• Operational models refleet how system elements perform operational 
activities, interactions among the activities, the sequence of operation of 
the activities, and performance and timing associated with the activities 
(Vitech). 

• Functional models reflect function decomposition, data flow among 
functions, the sequence of the functions, resource utilization, and 
performance and timing associated with the functions (Vitech). 

• Physical models reflect platforms, facilities, operational nodes, systems, 
personnel, and interfaces (Vitech). 

In the design and development phases of a program, systems development 
activities often fall into four activity domains—requirements, behavior, architecture, and 
Verification and Validation (V&V) (Vitech). CORE concurrently synchronizes the 
development of all four domains to ensure consistency and integrity between the domains 
allowing the architect to locate and correct domain discrepancies. Figure 15 shows the 
four domains and their interactions within the CORE construct. 

The MBSE process coupled with the CORE structure allows system architects 
and designers to effectively communicate ideas, with common language, to the various 
stakeholders. CORE deliverables include DoDAF “standard” views (AV, OV, SV, and 
TVs) each representing a different stakeholder perspective. Documentation artifacts are 
derived from the developed architecture and include hierarchical decompositions and a 
multitude of graphical displays to exhibit data. The output is a fully developed and 
integrated system architecture that contains specifications, design, and interface 
documentation. 
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utilizing a layered approach to progressively clarify and elaborate all four domains 
concurrently ensures consistency and completeness. 


Figure 15. CORE Domains. (From; (Vitech Corporation 2009)) 


2. Design Reference Mission Example 

a. Introduction 

A notional USV mission was explored to demonstrate how the DRM 
process can be used to help build the system architecture. A basic DRM was constructed 
for an autonomous USV in an oil platform defense mission. It describes the background, 
mission, threats, environments, and a tailored Operational Situation (OPSIT). 

b. Background 

A relatively tight margin exists between global oil production capacity and 
global consumption. Stable collection, production, and distribution of oil and natural gas 
are essential in maintaining the global economy. The threat of terrorist attack is a very 
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real threat to both the oil and gas field installations and to the transportation and 
distribution systems eonneeting petroleum fields to the markets. The threats of attack 
have resulted in higher market prices for crude oil and natural gas. These threats place a 
great deal of emphasis on oil companies and national and international authorities in oil 
platform security. This vulnerability makes offshore facilities an attractive target for 
insurgent organizations seeking to attack developed world economies. 

Unmanned systems are highly utilized in today’s military and are 
increasingly sought after for future military operations. Combatant Commanders 
(COCOMs) are asking for unmanned vehicles with ever-increasing capabilities to 
perform tasks that are considered dirty, dull, or dangerous for manned platforms. These 
tasks include: surveillance and reconnaissance; signals intelligence (SIGINT); mine 
detection; force protection; homeland defense; irregular warfare; and conventional 
campaigns. Unmanned systems have an unbounded potential to provide an affordable 
force multiplier to U.S. military and law enforcement. 

The next step in the technological development of unmanned systems is in 
the transformation from remotely operated, limited task unmanned systems into 
autonomous, multi-mission systems. In addition, greater efficiencies and improved 
interoperability could be achieved via an integrated, multi-domain, holistic approach to 
unmanned system design. The UV Sentry program seeks to identify how unmanned 
systems can be optimized to support a greater set of mission areas, identify those 
common areas of technology maturation that can lead to performance improvements in 
all domains, and identify the technology enablers needed to foster the ability to conduct 
collaborative operations between multiple unmanned systems in multiple domains. 

c. Mission 

In general, autonomous US Vs are desired to perform missions that require 
capabilities such as: 

• Persistent, wide area surveillance, tracking, and interdiction capability 

• Target discernment in a congested littoral environment 
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• ISR capability in potentially dangerous areas 

• Multi-domain deteet-to-engage capabilities 

• Automated data fusion into a common operational picture (COP) 

• Autonomous identification of suspect vessels 

In a seeurity role, the Autonomous US Vs must persistently search, detect, 
and identify suspect vessels, to a high degree of confidence, within a large amount of 
background shipping and aircraft. This mission is comprised of three main phases: 
Surveillance, Detect and Identify, and Intereept and Engage. 

The Surveillance phase consists of using area surveillance and 
autonomous colleetion and fusion of embedded and external sensor data to seareh for 
potential security hazards. This phase includes autonomous task distribution between the 
various platforms to ensure the most effieient and effeetive combination of assets is 
utilized. In addition, sensor data will be networked and fused to maintain a continually 
updated COP. This phase also includes automated launch, recovery, and refueling of the 
US Vs allowing the required fleet to remain on station for the appropriate endurance to 
perform the mission. The biggest challenge is in diseerning suspect vessels amongst a sea 
of legitimate background marine traffie. 

The Detect and Identify phase deteets contacts of interest (COIs) for 
further investigation. Identification data is used to develop traek histories and is matched 
against various onboard or external databases. Tracks without appropriate data or 
otherwise of interest are passed to unmanned surveillance systems for additional scrutiny. 
Based on the initial screening, USV develops surveillance traeks and calculates intereepts 
for COIs. If required, a human ean be included in the loop to approve or disapprove 
intercept plans. Intereept and elose-in surveillance vessels are then autonomously, or by 
human command, launched or directed toward the point of intercept. Automated systems 
route vehicles to the intercept point and establish elose in surveillance of the COT Input 
from multiple sensor and data sources is processed and fused to develop a detailed 
understanding of the target. Based on developed target data, a deeision on further 
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prosecution of the target may direct the vessel to: continue surveillance, end surveillance, 
direct manned intercept, for search, seizure, or arrest, or direct engagement with 
unmanned system lethal or non-lethal capabilities, if security environment demands and 
ROE permit. 

In the Intercept and Engage phase, unmanned platforms using various 
sensors including radar, EO/IR, and acoustic, to process, fuse, and verify target 
identification information upon intercept. The USV will utilize onboard and external 
assets and databases to support detection, tracking, identification and intercept. The 
vessel will intercept and track contacts of interests, autonomously launching and 
retrieving unmanned vehicles to backfill tracking vehicles as required due to refueling 
considerations. If it cannot track the COI due to speed, fuel, or geographic limitations, it 
will autonomously notify external commands of the targets location, course, speed, and 
altitude, if necessary, for intercept by other platforms or for early warning of an imminent 
attack. Manned assets may be used to intercept, board, inspect, detain, or neutralize threat 
platforms. UV Sentry will seamlessly integrate with these manned vehicles, providing 
operators and decision makers with information during transit to complete the intercept. 
Wide-area sensor platforms such as aerostats, aircraft, towers, or buoys, can provide 
automated communications relays. 

In an oil platform security mission, UV Sentry assets typically maintain a 
zonal defense structure made up of concentric area rings extending outward from the oil 
platform or field requiring protection. The outermost zone, or surveillance zone, typically 
extends to between 6,000 and 8,000 meters from the HVA. In this zone, the USV (and 
support assets) autonomously detect and track all contacts that enter the area. The next 
zone, or warning zone, typically extends to between 2,000 and 4,000 meters from the 
HVA. In the warning zone, the USV will autonomously warn all contacts they are about 
to enter the exclusion zone where they will be engaged. The closest ring, or exclusion 
zone, typically extends out to approximately 2,000 meters from the HVA and marks the 
threshold where the USV will interdict and potentially engage all known threats. The 
USV autonomously allocates assets to specific tasks, which include surveillance, 
interdiction, and warning. Elevated sensors can be used to provide radar coverage and 
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communication relays for the Area of Responsibility (AOR). At a minimum, radar 
eoverage is designed to loeate and traek all surface and air tracks in the surveillanee zone. 
Aeoustie sensors can be utilized to provide location and tracking data for sub-surface 
eontaets in the surveillanee zone. Radar and sonar eoverage will be aehieved by 
integrating networked assets ineluding: aerostats, towers, buoys, manned or unmanned 
aireraft (with radar or dipping sonar), undersea sensors, manned or unmanned surfaee or 
subsurfaee vessels, ete. Data from these distributed multi-domain sensors is automatieally 
fused to form a COP, whieh provides manned and unmanned operators with situational 
awareness and the means to alloeated assets and make engagement deeisions. Automated 
launeh, recovery, and sustainment eapabilities permit the craft to remain persistent in the 
surveillanee zone. Sensors deployed throughout the area of interest detect COIs out to 
just beyond the surveillanee zone. These COIs are tracked and when unusual patterns are 
deteeted, sueh as speed inereases, laek of Identifieation Friend or Foe (IFF) or Automated 
Identifieation System (AIS), and when they enter the surveillanee zone, an asset is 
alloeated to interdiet. Manned operators remain in the loop to monitor, and when 
required, approve/disapprove UV Sentry aetions. In addition, unmanned intereept and 
elose-in surveillanee vehieles are launehed, and later reeovered, through UV Sentry 
automated launeh, reeover and sustainment systems... 

d. Threats 

Threats to offshore faeilities may eome from a multitude of sourees in the 
air, surfaee, or sub-surfaee domains. Adversaries intent on destroying or disrupting oil 
produetion for politieal or financial means are highly capable of inflieting major damage 
to the vulnerable oil industry. Marginally sueeessful attaeks can affect world oil prices 
and destabilize nations. A highly sueeessful attaek eould result in signifieant eeonomie 
and environmental damage. Adversaries ean inelude state-sponsored militants, 
international terrorist organizations, domestie terrorists, or separatist organizations. The 
threats to oil platforms and infrastrueture are asymmetrieal in nature requiring persistent, 
highly eapable systems and proeesses. Speeifie threats inelude: 
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Air Domain; 

• Civil aircraft (armed attack or suicide bomber) 

• Armed UAV 

• Cruise missiles 

Surfaee Domain: 

• Armed Attack Boats (machine guns, RPGs) 

• Suicide Boats 

• Armed US Vs 

Sub-surfaee Domain; 

• Submarines 

• Semi-Submersibles 

• Armed UUVs 

• Swimmers 

• Torpedoes 

The most probable attack is likely to be from an explosive device onboard 
a small serviee or pleasure eraft boat. This attaek method could prove particularly 
difficult to defend if a Platform Supply Vessel (PSV) is used as an attaek vector. 

e. Environment 

The offshore environment presents a diffieult challenge for maritime 
forces. Persistent surveillanee and response area may span thousands of square miles to 
proteet hundreds to thousands of dispersed individual platforms. The traffie density of 
legitimate commercial traffic near oil field exclusion zones makes the environment 
partieularly ehallenging to protect. The proximity to eivilian and military air traffic 
routes, eommercial sea lanes, fishing areas, and land make detection and identification of 
potential foes a huge ehallenge. The enemy can disguise or hide vessels among a 
background of commercial and pleasure traffic. The sheer number of platforms, large 
area to be protected, magnitude of baekground air and surface vessels, political and legal 
eonsiderations, proximity to land, and littoral maritime eonditions make the projeeted 
operational environment (POE) particularly challenging to seeurity forees. 
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Environmental conditions that must be monitored and considered include: 

• Temperature 

• Precipitation 

• Visibility 

• Wind 

• Sea state 

• Weather (including dust/sand storms) 

• Undersea acoustic conditions 

• Radar propagation (Juctmg, etc.) 

The political and legal environment must be carefully considered 

including: 

• Rules of Engagement (ROE) 

• Host nation sensitivities and restrictions 

• International/maritime law 

• Business/financial considerations 

The USV shall operate in both open ocean and littoral waters in the warm 
waters of the Gulf of Mexico or the Persian Gulf to the cold waters of Alaska or the 
North Sea. Water temperatures range from 98 degrees Eahrenheit in the Gulf region, to 
45 degrees Eahrenheit in the extreme northern and southern oceans. 

/. Operational Situation (OPSIT) 

(1) Overview. This section presents a brief example of an 
OPSIT used to help identify capability needs for a UV Sentry USV operating in an oil 
platform defense mission in the fictitious partner nation of Manitobi. An OPSIT can be a 
vague or detailed as its author sees fit to convey the idea and be useful for analysis. Some 
sections are purposely incomplete in the interest of brevity. 
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(2) Situation. The Manitobi Liberation Army (MLA) is a 
growing terrorist organization with the knowledge and the means to infliet major damage 
on an oil platform. The organization is determined to destroy or disrupt oil produetion 
and distribution for the eountry of Manitobi. The government of Manitobi is a budding 
demoeraey attempting to rebuild the nation after an intense eivil war. The small nation¬ 
state is in desperate need of the profits it gains through its international oil sales from its 
only operating oil platform M36. The platform is two miles off the eoast of Manitobi on a 
reeently diseovered oil reserve below the oeean floor. The nation to the north of Manitobi 
is a major shipping port in the region. The eountry to the south is a vaeation destination 
harboring 20-30 eruise ships eaeh week along with a large number of pleasure eraft for 
fishing and sailing. Many of Manitobi’s people rely on fishing to earn a living. The 
eombined effeet of merehants, pleasure eraft, and fishing vessels make platform seeurity 
a major ehallenge. In addition, the platform’s proximity to land and other nations make 
seeurity a time-sensitive task. The U.S. has eommitted to defend M36 but assets are 
spread thinly throughout the world. 

(3) Mission. Proteet the M36 platform from a MLA attaek. 
Use a 6000m surveillanee zone, a 4000m warning zone, and a 2000m exelusion zone. 

(4) Risk. Grave eeonomie, politieal, and seeurity setbaeks if 
oil produetion is disrupted. Region destabilization eould result. 

(5) Employed Assets. The U.S. Navy employed a network of 
sensors and US Vs to proteet M3 6. There are eight US Vs eaeh with a doeking station 
attaehed to the platform. The aerial radar eoverage is provided by an aerostat attaehed to 
the North eorner of the platform deek. Sonar eoverage is provided by a series of 
disbursed bottom tethered buoys and the USV’s organie Sonar system. The U.S. Navy 
sent a erew of eight sailors to oversee the mission. The sailors monitor the USVs and ean 
interdiet, board, seareh, seize, and engage an enemy vessel using the team’s 11-meter 
manned vessel with a bow-mounted .50 eal maehine gun. The operations eenter is loeated 
on the M36 platform deek and requires one manned wateh stander present at all times. 

(6) Seenario. The Radar aerostat deteets three inbound surfaee 
vessels erossing into the surveillanee zone on a eourse toward the platform base at 
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approximately 30 knots each. IFF and AIS sensors determine the vessels are not 
identifying themselves as friendly, or vetted, craft. The UV Sentry system dispatches 
three US Vs toward the inbound vessels for interdiction and identification. As the US Vs 
close on the suspect vessels, the three vehicles rapidly open the distance from one another 
in an attempt to confuse the USVs. UV Sentry interdiction algorithms recognize this 
maneuver and command each USV to interdict a separate COL The USVs meet the 
inbound COIs near the warning zone and issue verbal warnings and close-in maneuver... 

(7) Summary. An OPSIT is entirely dependent on the intended 
mission and does not have a specified length or format. In this case, the OPSIT described 
a situation, mission, risk, employed assets, and scenario. The descriptions were included 
provide an example of an OPSIT and to show how it can be used to help identify mission 
essential tasks and required capabilities. 

3. Mission Thread 

a. Overview 

A thread is a mission-specific product that describes the basic tasks 
required to perform a mission function. Mission threads can be derived from OPSITs in 
the DRM to help develop test cases for specific system functions. The mission thread 
provided was developed to show a USV-focused example of how a DRM, OPSITs, and 
threads can aid in building the initial (before iteration) functional architecture. 

b. Thread Description 

A USV patrolling an established protection perimeter is continuously 

collecting, monitoring, and fusing sensor data to maintain the common operating picture. 

Among its other sensors, the USV uses ES equipment and an IFF/AIS transponder to help 

ID the COI as friend or foe. The USV identifies a vessel as a suspect COI due to its 

course, speed, and radar emission frequency. The USV alters course and speed to 

intercept the suspect vessel. As the COI alters course and speed, the USV reviews and 

evaluates the ever-changing situation and acts accordingly. The USV also communicates 

with all required assets and entities while navigating toward the suspect COI. As the 

suspect COI ignores warnings and enters the exclusion zone, the USV processes the COI 
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as a target. After the USV gains permission to engage the inbound COI, the USV’s lethal 
or non-lethal assets are employed to stop the suspect COI. 

c. Thread Navy Tactical Tasks (NTAs) 

The following tasks correspond to the thread description in section 3-b and 
the example OPSIT in section 2-f 

• NTA 6.3.1.5 Establish and Enforce Protection Perimeter 

• NTA 2.2 Perform Collection Operations and Management 

• NTA 5.5.4 Conduct Electronic Warfare Support (ES) 

• NTA 6.1.1.3 Positively Identify Eriendly Eorces 

• NTA 5.2.1.1 Review and Evaluate Situation 

• NTA 5.1 Acquire, Process, Communicate Information, and Maintain 

Status 

• NTA 1.2 Navigate and Close Eorces 

• NTA 1.4.7 Enforce Exclusion Zone 

• NTA 3.1 Process Targets 

• NTA 3.2 Attack Targets 

The tasks were mapped to their warfighter MOEs in the NTTL and were 
assigned applicable MOPs. Tables 1, 2, and 3 summarize the tasks, MOEs, and related 
MOPs. The MOEs are developed in warfighting simulation and the MOPs are determined 
from the USV system component architecture model. 
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Tasks 

Measures of Effectiveness (MOE) 

Measures of Performance (MOP] 

Units 

Measures 

NTA 1.2 Navigate and Close 
Forces 



Knots 

rate of movement. 

Speed 

Percent 

of maneuver force 

concentrated at decisive 
point prior to detection. 

Speed 

Percent 

of supporting force 
concentrated at desired 
point prior to detection. 

Speed 

NTA 1.4.7 Enforce Exclusion 

Zone 



Number 

vessels located. 

Speed/Endurance/Payload 

Number 

vessels identified. 

Speed/Endurance/Payload 

Number 

vessels boarded. 

N/A 

NTA 2.2 Perform Collection 
Operations and 

Management 



Percent 

of targets accurately 
identified. 

Payload 

Percent 

of targets accurately 
located. 

Payload/Endurance 

Percent 

of PIRs have at least one 
source that yielded 
intelligence information. 

Payload 

NTA 3.1 Process Targets 



Percent 

of desired results achieved 
by expected conclusion of a 
given phase or time line. 

Payload 

Percent 

of selected targets have 
accurate coordinates 

available. 

Payload 

Percent 

of targets susceptible to 
non-lethal kill allocated to 
non-lethal attack systems. 

Payload 

NTA 3.2 Attack Targets 



Percent 

of missions requested by 
components executed. 

Speed/Endurance/Payload 

Percent 

of high priority missions 
executed within the 
specified time. 

Speed/Endurance/Payload 

Percent 

of preplanned targets 
successfully attacked 
during operation. 

Speed/Endurance/Payload 


Table 1. MOE to MOP Mapping (NTA 1.2 to NTA 3.2). 
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Tasks 

Measures of Effectiveness (MOE) 

Measures of Performance (MOP] 

Units 

Measures 

NTA 5.1 Acquire, Process, 
Communicate Information, 
and Maintain Status 



Percent 

of units are in 

communication with 
commander throughout 
planning and execution. 

Payload 

Hours 

to process status 
information and 

disseminate to subordinate 

units. 

Payload 

Percent 

of available information 

examined and considered 
in latest status report. 

Payload 

NTA 5.2.1.1 Review and 

Evaluate Situation 



Hours 

since last review of 
commander's plans. 

N/A 

Percent 

of information coming into 
the headquarters, of which 
the commander has cyclic 
management. 

Payload 

NTA 5.5.4 Conduct 
Electronic Warfare Support 
fESl 



Time 

to rapidly reprogram 
warfighter sensors and 
seekers within the 
electromagnetic spectrum. 

Payload 

Time 

from receipt of data to 
classification to 

dissemination of tactical 

information. 

Payload 

Number 

of units with unresolved 
emitter ambiguities in the 
tactical picture. 

Payload 

NTA 6.1.1.3 Positively 
Identify Friendly Forces 



Minutes 

to confirm identity of 
unidentified target. 

Payload 

Number/Percent 

of forces accurately 
identified. 

Payload 

Percent 

of friendly casualties due to 
friendly actions. 

Payload 


Table 2. MOE to MOP Mapping (NTA 5.1 to NTA 6.1.1.3). 
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Tasks 

Measures of Effectiveness (MOE) 

Measures of Performance (MOP) 

Units 

Measures 

NTA 6.3.1.5 Establish and 

Enforce Protection 

Perimeter 



Y/N 

Were unauthorized 
personnel, vessel, or vehicle 
permitted inside the 
minimum standoff zone? 

Speed/Endurance/Payload 

Number 

of minimum standoff zone 
penetrations. 

Speed/Endurance/Payload 

Number 

of minimum standoff zone 
penetrations successfully 
repelled. 

Speed/Endurance/Payload 


Table 3. MOE to MOP Mapping (NTA 6.3.1.5). 


E. MULTI-CRITERIA DECISION-MAKING TOOL 

1. Overview 

Complex SoS like the UV sentry, consist of a multitude of interconnected systems 
and components. The tight coupling of these systems prevents the ability to optimize the 
overall system by optimizing each individual subsystem. This sets up a complex blend of 
system interrelationships of competing objectives. As systems become more complex, the 
ability to optimize capabilities becomes far more convoluted and difficult to improve 
using traditional methods. Multi-criteria decision-making methods and tools provide the 
means to optimize overall system performance by finding the optimal trade-off space 
between several competing system measures. MCDM theory and application could be a 
thesis topic by itself However, in this thesis, MCDM is just another tool in the SE 
toolbox used for concept exploration, trade-off analysis, and system design. 

2. Application 

The keys to effective concept exploration is both ensuring the entire design space 
is exposed and having the ability to understand and communicate tradeoffs with 
stakeholders. 

SAS JMP statistical analysis software was used as the MCDM tool to study the 
UV Sentry USV system design space. JMP software provides the means to utilize data 
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from the ship synthesis model to construct an effective and easy to use decision-making 
tool through DOE and RSM. JMP fuses powerful software analysis capabilities with 
dynamic data visualization providing the user with an interactive and flexible data 
management and display tool. 

3. Design of Experiments (DOE) 

DOE is a structured experimental approach to system or process analysis. The 
approach is used to quantify and examine multiple design parameter effects on an overall 
process or system design. The DOE is intended to “characterize” the system by 
determining which factors (variables) affect the response (outcome). System 
characterization is studied by conducting a screening experiment that uses fractional 
factorial designs. The screening experiment is intended to estimate the magnitude and 
direction of the factor effects (Montgomery 2001). After the screening test, the designer 
should be able to determine individual and combined (interactions) factor effects on the 
response variable. 

DOE is used to find the minimum number of experiments that must be conducted 
to yield an accurate representation of the design space. This allows the designer to 
effectively and efficiently capture the critical process factors and their corresponding 
effects on the response while minimizing effort and required resources. DOE accounts for 
all possible factor dependencies from the start ensuring the response data covers all 
individual and interaction effects. This gives the designer full situational awareness and 
allows for the systematic removal of factors that do not affect the response. 

4. Response Surface Methodology (RSM) 

RSM is a collection of statistical and mathematical techniques useful in the 

development, improvement, and optimization of systems and processes (Myers and 

Montgomery 2002). This structured process uses second order curve fits of desired data 

to generate a minimum collection of designs based on groups of factors that permit the 

study of an entire design space. RSM uses a series of mathematically predefined 

orthogonal point designs to model the input-output relationship, which is then displayed 

visually to represent the design space for decision making (Katsoufis 2006). RSM allows 
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designers and stakeholders to effeetively view the design space permitting concept 
exploration and tradeoff analysis. RSM is efficient, cost effective, and relatively simple 
compared to traditional methods. 

There are a number of experimental designs used in RSM including the Central 
Composite and Box-Behnken methods. Each design presents a different experimental 
methodology and must be selected based on which best fits the system or process being 
studied. The Central Composite is used to develop the model due to its inclusion of the 
extreme factor points at the box vertices. Figure 15 shows a Central Composite design 
cube with three factors. This allows the designer to explore the entire design space 
including the extreme minimum and maximum factor areas. 



The Central Composite design response surfaces require three levels for each 
factor to build the design space. Typically, threshold (minimum), midpoint, and goal 
(maximum) values are used as the three input factors levels. Determining an appropriate 
value range for each factor is vital to building a useful model. Designers should 
understand that these values determine the magnitude of the design space and must tailor 
their choices to build a precise model. A very narrow range may result in an exceedingly 
limited design space while a range that is too broad may result in a large fit error in the 
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regression equation, severely weakening the fidelity of the model. Designers must ehoose 
faetors and parameters wisely and understand the eonsequenees of their ehoiees. 

A seeond order RSM model is used to approximate the response onee it is realized 
that the experiment is elose to the optimum response region where a first order model is 
no longer adequate. The seeond order model is usually suffieient for the optimum region, 
as third order and higher effeets are seldom important. Figure 17 shows the response 
surfaee seeond order regression equation for k (the total number) faetors. 

y = bo + Z Vi + + X Z ^ 

1=1 i=l 1=1 J=i+l 

Figure 17. Response Surfaee Equation. 

The bo, bii, bij terms are eonstants determined from the multivariate regression, s 
represents fit error, and the summations represent linear, quadratie, and interaetion terms 
respeetively. This equation represents the quadratie response surfaee for a given response 

f- 

F. SUMMARY 

Chapter III deseribes the elements and method for the proposed MBSE, 
arehiteeture development, and deeision-making proeess to aid in the transformation of 
eapability needs to eoneeptual design for the UV Sentry USV. Chapter IV deseribes how 
to build the model and provides a brief ease study to illustrate its usefulness and 
applieations. 
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IV. MODEL-BASED ANALYSIS 


A. INTRODUCTION 

The model-based analysis for the UV Sentry USV was conducted, as a part of the 
overall MBSE method, using SAS JMP statistical software. JMP provided the means to 
build an effective MCDM tool by fusing DOE and RSM techniques with predicted 
performance data from the ship synthesis model. This method gives UV Sentry 
stakeholders the ability to explore the USV conceptual design space, perform tradeoff 
analysis, and to make informed design decisions in the early stages of preliminary design, 
where changes are cost-effective and easy to implement. 

B. CONSTRUCTING THE MODEL 

Model construction began with the selection of the ship synthesis model. 
Choosing a suitable performance prediction model is critical to building an accurate 
MCDM tool. Model performance estimations are the factor and response inputs to the 
RSM equation and corresponding response surfaces. If these values are not accurate, the 
RSM driven MCDM tool will not yield useful information. A prismatic planning hull 
model was selected due to its relevance and use in current USV designs. There are 
countless ship synthesis models available and appropriate for use in this MBSE process. 
Model selection depends on many factors including customer capability needs, program 
constraints, technology readiness, and risk aversion. If the design strategy includes 
exploring the feasibility of different hull forms, designers may choose to select a number 
of ship synthesis models to analyze and compare. The type or number of models selected 
does not affect the MBSE process or the construction of the MCDM tool. 

The next step involved building the design space. This process began by using the 
DOE feature in JMP to design the screening experiment. A three-factor Central 
Composite design was used to fully exploit the design space. Choosing the Central 
Composite design resulted in the fifteen tests shown in column two of Table 4. Vessel 
length, speed (velocity), and maximum duration (endurance) were selected due to their 
relevance in USV design. Payload capacity, displacement, fuel weight, and power were 
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chosen as the responses due to their importanee in USV design. The ship synthesis model 
was exereised to study the feasible high and low limits in the model. This step was done 
to ensure the parameters seleeted for each factor were within the feasible design spaee. 
This proeess was neeessary due to laek of data on speeifie prismatie planning hull point 
designs and the absence of speeifie capability needs and system eonstraints. The goal of 
this step was to determine aetual values for the threshold, midpoint, and goal values of 
each factor that cover a potentially desired design spaee. The process yielded values of 
32, 34, and 36 feet for vessel length and 24, 29, and 34 knots for ship speed. Three 
estimates for duration, 200, 400, and 600 NM, were ehosen as the threshold, midpoint, 
and goal values respeetively. Sinee maximum duration is an output in the ship synthesis 
model, the use of this variable as a faetor required the use of values as elose as possible to 
experimental design speeifieation. The input values for payload (eargo) and fuel 
pereentages were adjusted in an attempt to obtain duration values as elose to the 200, 
400, and 600 NM values as possible. The aetual model outputs were then used as factor 
values for the table. The response values from the ship synthesis model were recorded in 
accordance with the DOE in the JMP matrix shown in Table 4. 



Table 4. JMP Matrix. 
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JMP was used to process the DOE data to run the second-order, Central 
Composite RSM design model. JMP’s “summary of fit” function was used to check the 
fitness of the RSM equation/model. 


^[^Response Payload Capacity 
Actual by Predicted Plot 



0 1000 3000 5000 

Payload Capacity 
Predicted 

P=0.0339 RSq=0.91 
RMSE=808.48 

^ Summary of Fit 

RSquare 0.912262 

RSquare Adj 0.754333 

Root Mean Square Error 808.4845 

Mean of Response 2549.467 

Observations (or Sum Wgts) 15 

^ Analysis of Variance 

Sum of 


Source 

DF 

Squares 

Mean Square 

F Ratio 

Model 

9 

33981670 

3775741 

5.7764 

Error 

5 

3268236 

653647 

Prob > F 

C. Total 

14 

37249906 


0.0339* 


Figure 18. JMP Payload Capacity Statistical Summary of Fit. 


Figure 18 displays the payload capacity statistical summary of fit in JMP. The 
payload response appears to be a reasonably good fit with a R value of 0.91 and P-value 
of 0.03. The relatively tight grouping of points along the linear fit line confirms this 
assessment. 

Once the equation is determined to have a reasonable statistical fit, the model is 
used to study factor interactions, analyze design space point designs, and communicate 
design trade-offs. The model allows the user to easily apply and manipulate an infinite 
number of variations into the design space. JMP’s graphical interface enables the user to 
visualize design variants freeing the designer from the tremendous amount of work that 
traditionally goes into analyzing numerous potential point designs. The Profiler function, 
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presented in Figure 19, displays predietion traces for each factor. These “slices through 
the response surface” (SAS 2008) enable the user to change one variable at a time and see 
its effect on the predicted response. Evaluation of an individual factor’s effect on the 
model can quickly and easily be performed helping a stakeholder decide the importance 
and relevance of the various factors. 



CN CO kO CO CD O CM ''TO O O O O 

CO CO CO CO COCM CM CM CO CO COO O O O O 

CM CO ^ lO CO 


34 29 400 

Length Speed Duration 

Figure 19. JMP Prediction Profiler. 

The JMP graphical interface can be used to redefine the design space adding 
additional constraints and updating capabilities as stakeholders weigh in. Figure 20 
illustrates the JMP Contour Profiler feature. This is an “interactive contour profiling 
facility useful when optimizing response surfaces graphically” (SAS 2008). The profiler 
uses a 2-dimensional cross section of the design space to illustrate how the responses 
vary with respect to the selected factors. In Figure 20, duration is selected for the y-axis 
and speed for the x-axis. The responses (payload capacity, fuel weight, and power) are 
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displayed as colored lines on the plot. The shaded regions represent infeasible design 
space regions with respect to the limiting constraints, leaving the white space as the 
feasible design region. In this case, the high limits of 2,500 pounds for payload capacity, 
4,000 pounds for fuel weight, and 750 SHP for power were entered to illustrate the 
shading of the infeasible region. The crosshairs can be adjusted to show specific point 
values for various locations within the design space (under “Current X” in Figure 20). 
The contour profiler is a valuable tool to aid stakeholders in exploring and 
communicating potential designs within the design team. 
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Figure 20. JMP Contour Profiler. 
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The mixture profiler, in Figure 21, shows “response contours of mixture 
experiment models on a ternary plot” (SAS 2008). This feature allows the user to display 
and analyze the 3-dimensional response surface when there are three or more factors in 
the experiment are components in a mixture. 



C. CASE STUDY 

1. Introduction 

The following case study is a brief example of how the design model can be used 
to analyze a specific design concern regarding payload capacity. The example assumes 
the model is statistically fit and stakeholders are particularly concerned with the payload 
capacity of a proposed design for an 11-meter planing hull USV. 

2. Example 

Using the DRM and mission thread data from Chapter Ill, the USV design team 
built the initial system architecture and estimated the USV payload threshold to be 3,700 
pounds. The team used the MCDM model to test this estimate’s impact on the team’s 
goal of meeting capability needs in a successful design. A contour plot was used to study 
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the impact of speed and duration on the payload estimate, Figure 22. The lines represent 
different payload values, in 200-pound increments, from 2,500 to 5,100 pounds. The 
shaded region represents the projected infeasible region below the 3,700-pound payload 
threshold. This illustrates where various combinations of speed and duration fall in the 
design space with respect to payload. The crosshairs show that a design with a 27-knot 
maximum speed and 320-NM maximum duration lies on the edge of the feasibility 
region. If, for example, the capability needs necessitate the USV to attain a speed of 30 
knots with a 400-NM duration, the design team will suspect this point design to be 
infeasible requiring some form of action to take place. This step is useful but only 
considers deterministic values for speed and duration. The uncertainty involved with 
predicting the achievability of these values suggests that a probabilistic model is an 
improved way to investigate the design possibilities. 
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Figure 22. JMP Payload (case study) Contour Profiler. 
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Next, the design team uses the model to run a probabilistic simulation with 
random variable of speed and duration. The team uses triangular distributions for both 
variables with the lower, peak, and upper values shown in Figure 23. These values would 
be selected from subject matter expert estimations based on technology readiness, 
projected operational environment, and a number of “real-world” variations. Since the 
point design uses an 11-meter hull form, the length value is fixed at 33 feet. 
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Figure 23. JMP Payload (case study) Simulation Probability Functions. 


The team ran the trial simulation, using the JMP default of 5000 trials, to study 
the effect of length and speed variations on payload capacity. Figure 24 shows the JMP 
prediction profiler with the simulation results for payload capacity. The payload capacity 
distribution is displayed to the far right of the interaction curves with the simulation run 
mean and standard deviation listed below it. The simulation distribution and capability 
analysis are shown in Figure 25. The team included an upper and lower specification 
limit (USL/LSL) to represent their original maximum and minimum payload capacity 
values that were expected to meet predicted payload technology limits and system 
capability needs. Figure 25 shows the 5,000-pound USL and 3,000-pound LSL displayed 
on the distribution histogram (with box plot) and includes the specification limit “sigma” 
standard deviation data. The long-term sigma data is presented to show the chance that 
the outcome may fall outside desired specification limits, not to suggest anything about 
the process capability for this technology development study. This information provides 
the team with useful baseline data but will be much more valuable as the design evolves. 
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Figure 24. JMP Payload (case study) Simulation Prediction Profiler. 
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Figure 25. JMP Payload (case study) Simulation Distributions. 


Finally, the design team uses the JMP simulation cumulative distribution function 
(CDF) plot to study the speed and duration variability impacts on payload capacity. 
Figure 26 shows the CDF for payload capacity from the outcome of the simulation run. 
This plot is used to show the probability of n^ achieving success per a given payload 
capacity, with respect to length, speed, and duration. Although the reverse CDF is more 

useful and easier to understand, JMP does not currently possess the capability to plot the 

83 













































































inverse of eurve in Figure 26. Instead, to calculate the probability of achieving a given 
payload capacity, simply use the inverse of the probability read from the plot (i.e., 
subtract the value from 1). For example, by looking at the plot and using the inverse 
values, the team determines the probability of the USV achieving the desired speed and 
duration at the 3,000-pound LSL value is over 90% while the chance of accomplishing 
this at the 5,000-pound USL is less than 10%. As a further example, if investigation leads 
the design team to alter their payload weight estimate to 4,500 pounds. From the CDF 
plot they determine there is an approximately only a 15% chance that the desired speed 
and duration can be realized at this payload capacity with the current USV alternative. 
The team could then decide that the risk is too high for this alternative and would then 
explore corrective measures such as investigating lightweight payload component 
alternatives or interacting with stakeholders to see if lowering the maximum speed 
requirement, or operating multiple craft in tandem to lower endurance necessities would 
be acceptable in meeting mission requirements. 



2000 3000 4000 5000 6000 

Payload Capacity 

Figure 26. IMP Payload (case study) Simulation CDF Plot. 

D. SUMMARY 

The MCDM model described in this chapter is a highly effective analysis and 
communication tool for concept exploration and tradeoff study. The model is relatively 
easy to build and even easier to use. The program uses a commercial off the shelf 
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(COTS) software that is easy to find and install, and is eompatible with most DoD 
eomputer systems. The most difficult step in constructing the MCDM tool is finding a 
valid performance prediction model. The model, or series of models, selected must 
provide an accurate representation of the physical behavior of the system or component 
being modeled. If the performance prediction model is inaccurate, the MCDM model will 
follow suit. In this case, a planing hull model was selected to predict USV performance. 
If a different hull form is selected, the design team must find a model that accurately 
predicts the performance of the type of hull being considered. 

Input (factor) and output (response) variable selection is another critical step in 
the construction of the model. Variable selection is dependent upon their availability in 
the engineering synthesis models, the critical parameters of the system being designed, 
and the uncertainty of the relevant variables. In this case, length, speed, and duration 
were chosen to be the factors due to their relevance to the USV mission. The DRM set 
the baseline for the USV CONOPS and presented the system context and projected 
environment. From this, naval tasks were selected, from the NTTL, that formed mission 
threads required to meet system capability needs. These tasks were then mapped to 
applicable measures of effectiveness and to measures of performance (Tables 1-3). These 
measures of performance—speed, endurance, and payload—were all included in the 
model as either factors or responses. This method guarantees the warfighters’ mission 
essential tasks and associated validation measures are addressed in the model and in the 
design. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY 

The methods deseribed in this thesis are relatively straightforward but highly 
effective when integrated. The tools and techniques employed to build the MCDM model 
are not unique to this thesis. The original concept proposed herein involves the unique 
amalgamation of these established tools and techniques to construct an effective and 
practical MCDM model. The first three chapters describe the necessary background and 
contextual data to set an appropriate knowledge base for the rest of the work. The 
fundamental design concepts, scope and methodology, design tools and techniques, and 
UV Sentry/USV background data are described. Chapter IV tied the concepts together by 
describing how to build the model and stepping through an example of its usage. In 
addition, the model was used to study the impact of stochastic inputs and uncertainty in a 
design example. Chapter V provides conclusions for this work and recommendations for 
future study. 

B. CONCLUSIONS 

The MCDM model and techniques described herein provide the UV Sentry team 
with a highly effective conceptual design tool for developing an USV. The thesis offers 
an alternative approach to traditional conceptual design based on a capabilities-driven, 
model-based, SoS engineering process including explicit consideration of variable 
uncertainty. This holistic approach to system design keeps the design concepts and the 
designer in the feasible region with respect to physical, systematic, and capability 
constraints. The methodology is effective and the thesis presents a tool set to enable 
design, development, and assessment of alternative system concept architectures for an 
autonomous USV in a SoS context. The MCDM model enables designers to perform a 
solution neutral investigation of possible alternative physical architecture concepts. This 
ensures a consistent quantitative evaluation of warfighting capability, suitability, 
effectiveness, technology maturation, and risk before and during a program execution. 
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This effort is in support of an extended program to design a system of unmanned systems 
intended to provide the DoD with a eoordinated, multi-domain, multi-mission, 
autonomous seeurity and warfighting asset. 

The tools and teehniques presented in this thesis are only as good as the system 
designer that uses them. System stakeholders are still responsible for following good 
engineering and arehitecture development praetiees including proper problem definition 
and effective analysis of alternatives. System stakeholders must also promote adept 
communication and thorough tradeoff exploration in design development. This includes 
true, unbiased exploration of alternative system architectures capable of meeting 
capability needs. Preconceived notions of engineering solutions may limit the design 
space resulting in a sub-optimal system design. 

This MCDM method described is not limited to UV Sentry, USVs, or SoS. The 
concepts and tools are flexible and universal. The MCDM model is relatively easy to 
build, manipulate, understand, and change. It can be effectively utilized to aid 
stakeholders in making conceptual design decisions in the development process of any 
system, component, or SoS. 

C. RECOMMENDATIONS 

This work is a solid first step in the quest for ultimately developing a UV Sentry 
SoS. Some additional study would advance the ability to perform more extensive MBSE 
analysis and design. Recommended areas for follow-on study include: 

• Using an operational simulation of the warfighting capability to link the 
front end of an executable architecture model, connecting from the 
warfighting simulation used to measure the achievement of MOE, traced 
through the operational activity, operational task, function, requirement, 
and component elements to the UxV design spaces. This would provide 
quantitative input to stakeholders from an operational viewpoint. 

• Modeling the requirements specification limits in the responses to 
investigate robustness of MOE to MOP. This would provide the bounds to 
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achieve a quantitative technology risk assessment based on the uncertainty 
in the teehnology development and its impact on the aehievement of the 
warfighter’s needs. 

• Including cost-effectiveness-risk trade-off along with the teehnology 
impaet assessment on the USV. The system evaluation should inelude 
teehnology assessments with direet interfaee with UV Sentry teehnology 
areas, suitability evaluation, effeetiveness evaluation, eost analysis, and 
risk analysis. This would provide a holistie trade off assessment for all 
stakeholders to use for eonsistent deeision making. 

• Extending the USV methodology to allow assessment of eross platform 
interaetions aeross all UxV in order to perform SoS level trade-offs. The 
overall goal of UV Sentry is to define the optimal combinations of UxV to 
meet stakeholder operational needs, from mission eapabilities and 
operational aetivities. The allocation of functions must be allowed aeross 
the UxV platforms to determine alternative solutions in a SoS sense, and 
not by presuming speeifie platform eonfigurations of physieal 
eomponents. 
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